Developing Financial Applications using J2EE with

iPlanet Application Server

Traditionally, financial applications have been developed for proprietary networks such as private network of a brokerage company. Most financial applications were developed using “client-server” architecture, however, they were based on proprietary protocols and networks. As the popularity of the World Wide Web grew, it became important to bring these legacy financial applications online. The open architecture of the Internet and the request-response mechanism implemented by the web protocol -HTTP - poses unique challenges for financial applications.

This paper will focus on building online stock trading applications. All of the concepts discussed in this paper can also be applied to other types of financial applications such as banking or insurance. Requirements of an online trading web site are a superset of those for other financial applications.

Requirements

High volume and spikes

An online trading application, like other eBusiness applications, must be able to support heavy traffic volumes. Additionally, it must be able to sustain spikes at peak times. For example when the financial markets open at 9:30 AM EST, an online brokerage web site experiences thousands of traders attempting to login to begin their trading.

Scalability

This requirement is quite common in all web applications. As the web site becomes more and more popular and attracts more and more visitors, it must be possible to quickly add capacity by adding more servers, networking equipment, and/or communication lines.

Robustness

Like any other web site, robustness is an important aspect of financial web sites. The reality is that systems (hardware and software) do break down; therefore, the only way to have a robust site is by having enormous levels of redundancy built in to the entire web site infrastructure.

Security

Besides, having to sustain such high volumes, a financial application must also offer airtight security because the value of transactions can be quite high, and the information can be very confidential.

State management

This too is quite common in most web-based applications. HTTP is a simple request-response protocol. Every request is treated as an independent request, and once a response is sent to a request, the connection is broken (except under certain circumstances). Therefore, it does not have built-in support for “state-management”. Many real life transactions may span over several HTTP request-response pairs. Therefore, it is important to maintain state with respect to each client who is performing the transaction and.

External data sources

While most other types of applications can be developed using only a back-end database, most financial applications must communicate with external data sources such as a financial market data feed to provide real-time stock quotes, and an electronic communication network (ECN) to execute orders received via the web.

Architecture of an online financial application

The architecture that we choose must be able to meet those special requirements. So let’s analyze them one by one –

High volume, spikes and redundancy

Obviously, volume is directly proportional to the customer base of an institution. An organization with a large customer base will have much higher volume than one with a smaller customer base. However, in order to support growing web traffic, it becomes almost essential to have “load balancing” built in to the architecture. Sever load balancing refers to the ability to route requests to one of several servers in a manner that will attempt to balance the overall load on each server to obtain best performance from that server. There are several solutions in the market that can provide load-balancing capabilities. A nice review of load balancers can be found on the web at http://www.zdnet.com/pcmag/stories/reviews/0,6755,2457532,00.html. In this article, PC Magazine reviewed 7 load balancing devices from Alteon WebSystems, Cisco Systems, Coyote Point Systems, F5 Networks, Foundry Networks, Radware, and Resonate. Load balancing devices also address the issue of robustness by providing redundancy. If one web server fails, the request will be automatically routed to other remaining web servers. It also addresses the issue of scalability. If the 4 web servers installed in production are not able to handle all the incoming traffic, a 5^th web server may be added relatively easily. However, web servers only host HTML content, therefore, in order to add capacity for the web site, the entire online application must be designed to be scalable. One point to note, however, about using load-balancing devices to provide redundancy is that the load-balancing device itself must also be redundant in order to have a fully redundant infrastructure. Some of the “load balancers” reviewed in the article indicated above provide a “fail-over” configuration, in which two identically configured “load-balancers” may be setup such that if one fails, the other takes over until the failed one can be brought back online.

To support similar redundancy and robustness throughout the architecture, each backend service including the database must be implemented in a clustered environment. A clustered environment presents a single connection point for multiple redundant service providers. The application communicates with this virtual service provider, which is then delegated to any of the service providers that is currently functional.

One question that may be asked is “what happens if the second one fails, before the first one can be brought back online?”

In any such effort, a secondary option is usually considered sufficient. There is a very small chance that both may fail at the same time (or within minutes of each other) making it impossible to keep the site running, however, the likelyhood of this happening is quite low.

Air tight security

In many cases, a simple firewall is sufficient to protect the infrastructure behind it. In financial applications, however, a three-layered design must be used in order to provide maximum level of security. This is best implemented in a 3-tiered architecture using an application server such as iPlanet Application Server (formerly Netscape Application Server)

For this architectural set up, security begins with a firewall between the network and the Internet. Behind this firewall are web servers, which are set up with a bare minimum of services just to support the HTTP protocol and the application server component. Each web server has two network interfaces. First interface faces the first firewall, which provides connectivity to the Internet; second interface faces inside towards another firewall. Next, a second firewall is set up behind the web servers to provide a second line of defense. Behind this firewall is a set of application servers. These servers receive requests from the Web servers and return responses that are then routed to the client’s browser via the web servers. The application servers themselves have two network interfaces as well. One of the interfaces communicates with the web servers through the second firewall, and the other interface communicates with the back end services through another firewall.

State Management

State management is a common requirement of most web-based applications. All application servers mentioned in this paper provide a way to maintain state of the HTTP connection using a mechanism called “cookies” or special codes in each request. However, for financial applications, this special code must be encrypted so that unauthorized users cannot mimic a customer’s state and access the site. iPlanet Application Server has fairly robust and secure client state management features. Secure state management can also be implemented using traditional web programming methods such as NSAPI and CGI. Development can be done much more rapidly, though, using a standard web development framework provided by those application servers.

External Data Sources

An online trading application must be able to present “real-time” financial market data to its users. In order to do this, it must interface with a market data feed to obtain real time data from the exchanges. Financial market data feed is provided by many vendors all across the world. Reuters has the highest market share in this category. Reuters provides a C++ class library that may be used to interface with the feed. In a three-tier model, the web server communicates with the app server, and components on the app server communicate with the Quote server – therefore, the Quote server must be able to support multiple simultaneous conversations. This presents another challenge. Traditional data sources such as Databases like Oracle or DB2 have quite robust client/server frameworks that allow a web-based application to have numerous simultaneous conversations with it. However, in the field of the market data, there are so many diverse formats of the feed that no single framework has evolved to the level of sophistication of databases. While it is possible to create a new connection to the service each time it is needed, it is highly ineffective. The time required to make a connection and break it is far greater than that required to service a request. Therefore, it is important to create a persistent connection with the service that provides this data. iPlanet Application Server provides ways to augment their services using extensions such as Enterprise Java Beans, which allow an application to create persistent connections.

In addition to gathering financial market data, an online stock trading application must also communicate with the Electronic Communication Networks (ECN). An online stock trading application must send all orders that it receives via the web to an ECN for execution and must be able to maintain a persistent connection with the ECN to receive execution reports as they come. As the application receives execution reports, it must update the database to reflect the positions held for that customer. While this is very similar to the communication with the financial market data service, the important thing to note about this service is that it may receive responses to requests out of order. That is, an order that is sent out later may be executed before an order that was sent before it. And hence the nature of communication with the ECN must be completely “Asynchronous” – i.e. the application must not wait for a response after sending the request, and must be designed to accept unsolicited messages (responses to requests that it had sent earlier). This poses another unique challenge. Since Web protocol is inherently a request-response model – a request that originated from the browser, must be responded with valid data. When a customer places an order to buy shares, the order is accepted and a message is sent to the ECN. When the order is executed, a reply from the ECN is received by the service. By that time, the connection with the browser has been closed. According to HTTP protocol, communication may be initiated only by the browser. This order/execution type of communication requires that the server initiate communication with the browser to inform the client of the trade execution. One method of accomplishing this is to have a Java Applet or web page continuously poll the server at a regular interval to check if an order placed has now been executed. An alternative approach is to have an applet (or a COM object) on the client machine listen to a pre-determined port and have the server initiate a connection to this port when a trade is executed. This is called “Push technology”.

Conclusion

This paper set forth a viable architecture for developing financial applications with the iPlanet Application Server. Applications utilizing the components described will be robust enough to handle high volumes of traffic and spikes in use. It will also be extremely scalable – more hardware can be easily added as traffic grows. In addition, multiple firewalls provide airtight security for this confidential data. This approach is designed around the iPlanet Application Server, and Oracle architecture, but other App servers have similar components that make it possible to use the same design.

IPlanet App Server’s web connector plug-in redirects all requests to the Application server. Within the Application server, all business logic is implemented in objects called “servlets”, and all presentation logic is implemented in “java server pages” to provide maximum flexibility. The Quote services are provided using a stateless, Enterprise Java Bean which provides connectivity to the Financial Market Data feed and an additional component “Trading Server” constantly looks at the database for incoming orders, and sends them out to the ECN for execution and inserts execution responses into the database as it receives them from the ECN.

Anil Gurnani