Considered almost experimental just a few years ago, distributed object technologies have gained a strong foothold in the financial services industry. Expersoft, for example, has delivered distributed object infrastructures to such institutions as Chemical Bank, Goldman Sachs, Canadian Imperial Bank, American Express, Fidelity Investments, and National Australian Bank.
The financial services industry is ideal for this technology. Development projects often have a strong focus on component reuse, must support a variety of network communication models, and must deliver reliable code quickly. Distributed objects are a perfect tool for meeting all three of these requirements.
The following case studies and scenarios demonstrate how Expersoft’s PowerBroker products can be applied to a variety of financial applications, including electronic commerce, derivatives trading, portfolio management, foreign trading, real- time update notification and shared calculation servers.
Case Study: Electronic Commerce and On-line Banking
More than $10 billion worth of retail banking transactions occurred electronically this year, and that number is expected to increase as customers grow more technically savvy and as financial services companies realize the potential cost savings. In creating these applications, distributed object technology can play a major role.
Consider the experience of a leading developer of personal finance software, which is using Expersoft’s PowerBroker tools to provide on-line electronic banking services. The system will allow individuals to keep track of expenses, write both standard and electronic checks, inquire about balances, and access other financial information. The service will ultimately support some of U.S.’s largest commercial banks, with a client base that is expected to grow rapidly over the next decade.
The diagram below outlines how the system will work. An individual’s computer gains dial-in access to a set of distributed services-some offered by the bank, others by the provider-which are included along with the home finance package. These services include security features, information distribution, and features which electronically interact with the supported banks.
All interfaces between the banks and the provider are defined in the CORBA 2.0 IDL (interface definition language), which is compiled by the PowerBroker compiler and accessed using remote method invocations supported by the PowerBroker ORB. The IDL in effect defines a service contract between the banks and the provider, with each implementing their respective responsibilities. The PowerBroker Orb ensures that service requests and responses are delivered to the proper parties, while the PowerBroker administration tools allow the banks and the provider to manage the various server processes. Expersoft products enable the software provider to deliver critical services to its customers that would have been difficult to implement using a traditional architecture.
Multi-tier Cache and Data Servers
Financial applications must support large numbers of users who share data stored in different types of databases spread across the enterprise. Applications might also require real-time notification of data and events. In addition to accessing relatively stagnant data stored in a database, these applications also need immediate access to highly volatile data that is time critical. Let us use a trading application as an example.
Many brokers sell the same stocks or bonds. In a typical system facilitating these sales, all client applications directly access the database. By contrast, a distributed object approach might utilize PowerBroker’s capability to distribute an arbitrary service as a remote object. Here, instead of going directly to a database, clients would access a PowerBroker object server. The server provides distributed access to a trading service, which, in turn, accesses the database. This approach of isolating the client application from the database adds considerable flexibility and allows for additional functionality not supported directly by a database. Such an architecture is supported directly via the PowerBroker APIs, class libraries, preprocessor and IDL compiler. It can be supported either directly through the CORBA 2.0 standard or through extended distributed object services.
In addition to accessing stored data, a trading service might also combine data from different databases or might perform complex calculations. For example, a trade service might cache data-such as foreign currency exchange rates-across different trades. Such an architecture would yield significantly higher performance because an object-based service can make use of domain-specific knowledge not available in a generic database server. A PowerBroker-based service also enables the installation to easily change data models and database vendors at a later date. Moreover, developers can maintain and update the trade service without altering clients of the trade service. Once developed, the trade service can be leveraged across the entire enterprise.
In addition to accessing the relatively stagnant data managed by the trading service, applications might need access to real-time data-such as a stock quote. This information might come from a market data service or exchange rate service that is deployed in addition to the trade service. Such object-based services can be leveraged across the entire enterprise-not by responding to requests, but by distributing data to applications as often as they require. Doing so results in services that can distribute data to client applications as a notification, instead of as a response to a request. For example, when placing a foreign trade, the system need not retrieve the latest exchange rate from a request/response based rate service. Instead, the system simply distributes the current exchange rates directly to the trading service.
Market data must often be distributed in this way as well. It doesn’t really make sense for applications to poll for the most recent prices. Rather, the market data server, which “knows” when prices have changed, should take the initiative in distributing this data-utilizing a data distribution platform such as Reuters or Telerate to obtain the latest prices.
PowerBroker’s object-based, event-driven messaging allows for the development services that can interrupt interested clients when a particular event has occurred. This capability differentiates the PowerBroker ORB from almost all CORBA products on the market. Using a pure CORBA approach to provide this functionality can lead to increased application complexity, dangerous application polling or costly performance bottlenecks associated with using a database as a communication facilitator.
Some Expersoft customers have utilized a request/response interface alongside event-based object messaging to develop very sophisticated services. Consider what happens when an exceptionally large trade is about to take place on a PowerBroker-based trading system. Since the trade service is shared by the entire sales force, it can be used to notify others of the trade in addition to responding to requests that originate from the sales applications. In doing so, the trading service can take advantage of the same notification capabilities that were used to develop the real-time data service described above. The PowerBroker object broadcast mechanism can be leveraged within the trade service to ensure that all connected sales applications are notified of critical orders placed by other sales people. Again, PowerBroker allows a complex service to be developed that might otherwise have proven too difficult to implement.
A similar application architecture is currently in production at a Wall Street bank (see diagram below). The architecture supports many users, provides quick response times, supports real-time update notification, and requires a minimal number of actual database connections. It allows many sales traders to run several applications on their individual workstations sharing common data. Because of this architecture, the applications running on a given workstation will not require excessive resources or present any hidden integrity problems. Even though the applications share common data and all have update capabilities, problems associated with duplicate data and a high degree of concurrency are avoided, as are excessive resource requirements associated with storing the same data in several applications.
The architecture consists of a data service and feed service each running on high- end SMP machines, and a cache service with several GUI applications running on each workstation. To place an order, a GUI application makes a request to its cache service. The cache service then submits the trade to the data service, which provides all Oracle access while offering increased performance, reduced resource requirements and the elimination of integrity problems. The caching service runs on each client workstation and makes requests to the data service. GUI applications access the local cache service directly, while the cache service accesses the data server only when it needs data which is not cached.
In addition to servicing requests from the various cache servers, the data service notifies all cache servers if any of their cached data has been changed. Similarly, a cache service will notify all GUIs if any of their displayed data has been changed at the request of another GUI application. In other words, if several GUI clients are displaying the same data and the cache service modifies the data at the request of one GUI, the other GUI clients will be immediately notified with the new data, as well. Because of these procedures, all displayed data is guaranteed to be current at all times. The three-tiered architecture supporting both request/response and real-time notification provides up-to- the-second information along with excellent performance and resource utilization.
Enterprise Wide Internal Infrastructure
The brokerage community has been among the first to reduce development times and costs by reusing components across various departments, thereby eliminating the need to build the same or similar systems more than once. This approach also ensures that different systems developed by different departments can interoperate.
Traditionally, installations standardize on a particular set of tools-only to discover that different applications still need to be heavily modified to support cross- department communication. At this point, the firm might decide to start an infrastructure group and mandate the use of its API across all departments. The infrastructure group is then responsible for delivering robust API class libraries to support general application development along with financial business services. General development requirements include GUI building, messaging, and DBMS access. Business services include trading, calculators, and portfolio management. The infrastructure group then implements the desired APIs or class libraries, leveraging commercial off-the-shelf software whenever it is available and satisfies their requirements.
Expersoft provides a number of products that accomplish this goal. Internal infrastructure groups at several of the largest financial services companies have implemented portions of their internal infrastructure on top of Expersoft products. A high level diagram of such an infrastructure is included below.
The distributed object paradigm allows the building of business services separately from the applications that use them. By providing a framework for distributing C++ classes and CORBA interfaces, PowerBroker allows services to be spread across different machines, programming languages and network topologies. The distributed object paradigm supports a request/response model, which has proven very effective at addressing calculation engines. PowerBroker supports the distributed object architecture defined by the CORBA standard along with additional extended functionality for providing pass-by value, asynchronous invocation and real-time object messaging.
Typically a department develops components using the internal infrastructure framework and guidelines. The infrastructure group hides the PowerBroker APIs and class libraries within their own component development environment. Application developers can then build department solutions with the corporate framework. By utilizing the common framework and a component based methodology, developers ensure that department solutions will take advantage of currently deployed services. Departments can avoid rebuilding application components and allow other departments to leverage their development efforts. With a PowerBroker-developed framework, all corporate components support a high degree of scalability and provide the needed performance. PowerBroker administration tools can also be used to manage deployed components, with the PowerBroker replicated namespace helping ensure component availability while providing location transparency.
PowerBroker also supports a high-performance, object-based messaging and broadcast capability. Some firms have utilized this for real-time distribution of messages, updates or notifications. One advantage of PowerBroker is its ability to deliver true object orientation. While other messaging tools let structures be passed between networked computers, PowerBroker allows the messages to be composed of C++ class instances-allowing for easy integration with third party or internal class libraries. Passing objects by value instead of by structures allows a message to be easily re-implemented to provide different or enhanced functionality, while still providing the same semantic operations. In addition, the application developer does not need to know the internal composition of the message. With object-based messaging, the object, not the application, “knows” how to implement its own functionality-a capability not found with many other messaging systems. PowerBroker object-based messaging provides robust capabilities for specifying priorities, managing event processing, and performing logical broadcasts.
Organizations can reap many benefits by insuring that different departments use a mandated infrastructure built on top of PowerBroker, including the elimination of development costs associated with building application functionality more than once. The PowerBroker-enabled infrastructure will ensure that components can be leveraged across the organization. Additional benefits like interoperability and reduced maintenance costs will be achieved as well.