In-Depth

Brokerage firm developers use Corba IDL to

• By Peter Fischer, Max Dolgicer
• July 24, 2001

Brokerage firms are concerned with the inherent risk associated with holding a set of securities. Due to market volatility, the value of their holdings can dramatically change over a short period of time and thus quickly alter the fortunes of the firm. To protect themselves from risk, brokerage firms use a series of analysis and calculation routines that enable both brokers and traders of the firm to evaluate their portfolios. Such Risk Management Analysis is done on both a daily basis with the Profit and Loss (the so-called P & L), and over time using time curve analysis routines.

One major Wall Street firm faced the challenge of empowering traders and brokers with the ability to use Microsoft Excel to do their analyses. This firm has a huge investment in Microsoft technology on the desktop and the users were enamored of the functionality that Excel provided. The struggle facing the firm's enterprise developers was how to make the functionality that resided in different server platforms available to the Excel developers.

This business problem was viewed as an opportunity for introducing object technology to the company. This firm took up this challenge by creating an architecture that provided the risk management functionality in the form of a series of multitier business objects, thereby "objectizing" the enterprise.

Because it was an early attempt by the firm to move to distributed object technology, the technical team sought to avoid vendor lock-in with proprietary products and to gain an in-depth knowledge of how to develop distributed object applications. A goal was to build both a base of knowledge and a technical infrastructure upon which to build future systems and to provide extensibility to the system being developed.

The Runtime Architecture Client applications call the legacy application through an IDispatch or custom interface which is then routed to a Corba server which interfaces with the legacy application. Fig. 4 Source: International Systems Group Inc.

The existing analytic routines running on Unix midrange boxes were wrapped as objects using Corba. In doing this, the legacy applications could be leveraged, and they still provided functionality for the existing business systems. On the client side, these objects were wrapped as COM objects using both Automation and custom interfaces. This allowed the functionality provided by the analytic to be pushed to the Microsoft desktop and made these business objects accessible from a multitude of languages and productivity tools, such as Excel and Word. (See Fig. 4.)

The development effort was split into two parts -- client development and server development. The legacy applications were to be wrappered as object servers to be plugged into the new object-oriented infrastructure being put into place.

First object-oriented analysis and design was done to create the object model from the legacy applications. From the model, the developers generated IDL. Running these IDL files through the IDL compiler that came with the ORB yielded proxy and stub files that were needed to create the client and server objects, respectively. The files provided the communication abstraction for the specific ORB, allowing the developers to focus in on "filling in the blanks" with code.

The object servers on the Unix side were built using the stubs generated by the IDL compiler. These objects provided the interface between the legacy system and the clients by mapping calls from the new object interfaces to the legacy applications. The server stub methods were filled in with calls to the legacy applications. The calls returned data from the legacy applications to the client application.

The client side Automation server was built from the proxies generated from the IDL compiler. Using Visual C++ and the ClassWizard provided a rapid way to create the IDispatch interface and empty methods to implement the Automation methods. The bulk of the work was then simply implementing these methods by calling through to the appropriate object server method that performed the functions. In order to reference the remote object server, an instance of that server was created in the Automation server initialization code.

OLE/COM-Corba combination Integration for OLE/COM-based desktop client applications with enterprise Corba servers present a powerful combination. Fig. 5 Source: International Systems Group Inc.

The business solution code was written in Microsoft Excel using Visual Basic for Applications (VBA) to access and manipulate methods on the Automation server. These methods returned the data that was needed for the spreadsheet analysis that was carried out by the traders. These methods were packaged into Excel macrosheets and the charts and graphics were incorporated as worksheets. All the trader had to do was fill the appropriate data in the worksheet and hit the Start Analysis button.

The VBA code then performed the calculations by calling the methods on the Automation server, which called through to the object server on the Unix side, which in turn called into the legacy applications. After the results were returned to Excel, the charts and graphics were automatically run. This development laid the ground work for any technology on the client (not just Visual Basic) to be able to access new or existing Corba servers. (See Fig. 5.)

The big win for the development team was that this approach produced the right result. During a post-mortem examination, the team reached several conclusions. First, they learned that their chosen solution was labor-intensive, in that it required them to craft a significant amount of code in both the Automation and object servers.

The knowledge gained from the effort was time well spent. Members gained an understanding of ORBs, COM and how the technologies work, as well as an appreciation for the power of distributed object technology. The team authored a repeatable process to complete the project, as well as a baseline which could be extended with future functionality.

The team generated code that will lessen the implementation effort for future endeavors. The fact that the basic business functionality code was separated from the ORB-specific code, enabled the reuse of this codebase with other Corba-compliant ORBs. Thus the team avoided vendor lock-in, a significant concern going into this project.

The company's big win was the ability to access those server objects from a variety of client environments. Although this implementation used Excel as the client, more robust solutions using Visual Basic and Visual C++ are under development. Because those server objects were packaged as Automation objects with dual interfaces (i.e. support for custom, C++ interface), they were accessible from both of these languages.

-- Max Dolgicer and Peter Fischer