J2EE

Financial institutions have heavily invested in J2EE and component-based architectures. WebLogic Server is a key e-business platform for deploying innovative financial services to clients and trading partners. The emerging service-oriented architecture paradigm is a natural extension to J2EE, and WebLogic integrates it seamlessly.

Component and Business-Process Reuse
Component reuse is the key to building large-scale business-to-business (B2B) financial services; this article illustrates the benefits of doing so using the WebLogic platform. The most fundamental shift introduced by e-business is that the core business logic is now located and managed on the application server. Furthermore, business logic is now accessible from various presentation channels. WebLogic is a powerful platform for enabling centralized business-process reuse. If you provide the business processes to an Excel spreadsheet, you simply have to encapsulate it as a SOAP service, and WebLogic greatly simplifies the task.

Application Topology and Business Patterns
Taking a step back, it's interesting to note some of the essential e-business patterns emerging in finance. In its simplest form, a business pattern describes the interactions between users, businesses, and data. In that sense, a pattern-driven approach to building e-business architectures around WebLogic is very interesting. A J2EE architecture, in a nutshell, can be mapped to different business patterns such as the user-to-business, or "self-service," pattern; the user-to-data, or "information aggregation," pattern; and the B2B, or "extended enterprise," pattern.

Once you've identified the e-business pattern your financial service follows, the next step is to map it to an application topology, which in turn maps to a runtime topology. This article will concentrate mainly on the user-to-business pattern for financial services but will also address the extended enterprise with applications such as Web services.

For the user-to-business pattern, two application topologies have been identified. In topology 1, your application doesn't interface with legacy systems or third-party applications. This typically happens when you build a "pure" J2EE application that doesn't require the WebLogic Server to interface with legacy systems. In topology 2, your application interfaces with legacy systems or third-party applications. This is most common in financial services that require access to real-time data feeds, ticker plants, and third-party portfolio management systems.

Runtime Topology
Once an application topology has been identified, it must be mapped to a runtime topology, which is eventually deployed as the e-business solution. The following is a nonexhaustive list of the essential financial services for the user-to-business pattern:

• Access to real-time financial news and data feeds
• Notifications and alerts on events such as trades or quote values
• Real-time trading of financial instruments
• Portfolio valuation and reporting

Not surprisingly, customers have come to expect these services to be delivered seamlessly on mobile devices with the same level of functionality they would have using a Web browser. Financial services have to be designed with a multichannel architecture from the ground up. Figure 1 illustrates a runtime topology that I've found effective when building large-scale, multitier financial applications with WebLogic.

Nodes
A runtime topology consists of several nodes, which identify specific functions such as firewalls, Web servers, and directory services like LDAP. Each node is important in building an enterprise trading system around WebLogic.

The nodes in the "outside world" represent different actors that interface with the financial business processes. An actor can be a private or institutional client, another application communicating through Web services/SOAP, a brokerage firm using the FIX protocol to book and acknowledge trade orders, or even a mobile client. One or several actors initiate most of the system use cases.

A first firewall node restricts access from the Internet and filters traffic based on a set of rules. For example, most banking applications use https encryption with a firewall enabling only certain IP addresses and Port 443. A second firewall node restricts access from the demilitarized zone (DMZ) to the internal corporate network. The presentation channels and other nodes, such as mobile gateways or FIX engines, are located in the DMZ.

The Web server node (WebLogic in this topology) hosts financial Web applications. In most cases, the applications provide customized front ends for services such as portfolio management, e-reporting, and access to financial data and news. Clients use the Web channel; however, most business logic processing is delegated through RMI/IIOP to EJB components located behind the second firewall.

The FIX engine node is a highly specialized messaging engine for producing and consuming messages encoded in FIX, an industry-wide open protocol developed specifically for real-time, seamless electronic exchange of securities transactions. FIX enables you to provide straight-through processing, which reduces transaction costs by virtually eliminating phone calls and faxes between traders and brokers. Usually, a FIX engine must meet the same high-availability criteria as the other runtime nodes; therefore, most engine vendors incorporate clustering and failover in their products.

The Web services server node provides the infrastructure to map SOAP invocations to EJB session facades hosted behind the second firewall. Do this using RPC-style invocations where an inbound SOAP message arrives at the Web services server. The server parses the message and invokes an EJB session facade using RMI/IIOP, which in turn manages local calls to session and entity beans hosted by WebLogic. This illustrates the benefits of packaging reusable financial processes as EJB components, which can be leveraged by Web applications and by SOAP clients. RPC-style invocations are ideal for providing pricing or portfolio optimization analytics as Web services, which offers many new opportunities to share processes internally or externally.

The mobile gateway node provides the bridge between enterprise financial processes and mobile platforms such as Symbian, Palm OS, and Windows CE. With the advent of more powerful devices and richer user interfaces, mobile users will expect the same level of functionality provided by desktop applications. WML hardly delivers in that sense. Using a mobile middleware infrastructure based on JMS is an interesting approach. Such a solution relies on three components: WebLogic as a JMS provider for the financial business logic, data synchronization, and security; a mobile JMS gateway; and a very lightweight JMS client library residing on the mobile device. iBus//mobile from Softwired, Inc., (www.softwired-inc.com) seamlessly integrates with WebLogic for building mobile services with JMS. Because mobile platforms have problems such as intermittent connections and broken communication links, providing queuing facilities and reliable messaging is a necessity - JMS messaging is the ideal candidate.

The bulk of financial processes are located in nodes behind the second firewall. In this case, the WebLogic Application Server node is a central repository of reusable financial business processes packaged as session beans, entity beans, and message-driven beans. The ultimate goal, component reuse, is achieved by identifying the fundamental services recurring in all large-scale financial applications and encapsulating them as EJB components. Component reuse can be hard to achieve; however, today's fast-paced market leaves no choice other than relying on a solid, well-tested set of essential components.

The directory services node is essential for creating a single sign-on infrastructure. Single sign-on not only eliminates the hassle of managing multiple user logins and passwords, it greatly simplifies overall administration tasks. An LDAP directory can also store generic information such as e-mail addresses or, in the case of strong authentication, user certificates. From an application development perspective, centralized data stores for user management are great because the same authorization and authentication business logic aren't reproduced in each application. A slightly different runtime topology would add a read-only "slave" LDAP directory located in the DMZ. The write master stays behind the second firewall, and replication is used to synchronize master and slave nodes. This solution has the advantage of scaling better.

The quote server, or "ticker plant," node is a real-time market data distribution system like the Reuters Triarch. The ticker plant uses TIBCO's messaging technology for dispatching JMS quote messages in real time from TIBCO Rendezvous messages to the client application nodes.

Client application nodes are GUIs used for managing portfolios or entering trade orders. Except for the processing of real-time quotes, the bulk of the business logic behind the GUIs is actually implemented as EJB components hosted by WebLogic and reused by the Web tier.

The trade processor node is a back-office system used for settling and clearing the trades. Financial business processes hosted by WebLogic send JMS trade messages to the trade processor, which after acknowledging a trade returns a JMS message to a message-driven bean.

Finally, the Reuters Investor node( http://rfs.reuters.com/investor) provides financial data and news in an XML format to financial components hosted on WebLogic. The Reuters Investor service and the quote server differ in that the Reuters Investor service is used for building financial portals from the flexible Reuters data feed and the quote server targets real-time financial data streaming for trading.

Using clustering at the different nodes, such as the FIX engines, mobile gateways, and WebLogic servers, enhances reliability and availability. Horizontal scaling is achieved through clustering. Adding resources such as CPUs and memory to the server machines achieves vertical scaling. In this topology, WebLogic is used as a Web server in the DMZ and as an application server in the internal network.

Service-Oriented Architecture
Using WebLogic in the DMZ makes sense, especially with the additional features provided by WebLogic 7.0 and tools such as WebLogic Workshop. The runtime topology is also simplified because WebLogic simultaneously plays the roles of clustered Web server and Web services node. However, there's an even better reason for using WebLogic Server to build service-oriented architectures. If you've played around with WebLogic Workshop, you've probably seen how easily Web services can be built and published. It isn't a secret; we all know the next step in enterprise computing is service-oriented architectures. The real issue is how to get there as painlessly as possible. Many believe service-oriented architectures represent a fundamental shift in the design of enterprise software - with a tool like WebLogic Workshop, it's more a question of extending and adapting enterprise software than a fundamental shift. After all, you still have to develop J2EE components, and you still have to apply J2EE patterns. The difference is that now you have to consider service facades.

In most cases, business processes are complex and require multiple asynchronous steps. Even the simplest of financial processes, such as a trade order, might engage complex workflows spanning multiple days and requiring the intervention of many actors. As illustrated in Figure 2, the real fundamental shift happens when you visualize software architecture and development as a process-centric discipline. Most interesting is the ability to build models of processes and publish them as Web services.

Putting WebLogic Workshop to the Test
To evaluate WebLogic Workshop as a process-centric software development tool, I "redeveloped" an application I'd helped build.

Bank A wanted to sell funds to Bank B. Bank B would in turn sell those funds to its clients by providing tailored portfolios. The process involved several complicated steps and business rules. In addition, Bank A's IT infrastructure was totally incompatible with Bank B's.

We devised the relatively inelegant schema of exchanging information by sending and receiving daily batches of files. The business-logic tier then processed the files to validate trades and orders. The process required a lot of manual intervention, and I had an "I-could-have-done-better" feeling at the end.

Using Web services to solve the problem would have been great, but until recently it was still considered experimental technology. With WebLogic Workshop, this is no longer true. I was impressed with how fast I could prototype and redesign the application as a set of Web services and gradually visualize the entire workflow. I showed the results to a business specialist with little knowledge of software engineering. Thanks to WebLogic Workshop's visual interface, he was able to provide feedback, and we modified and adapted the business model interactively.

Separation of Roles
The goal of the runtime topology is not only to provide a secure, scalable, and reliable environment, but also to promote a separation of roles between developers. The runtime topology in Figure 1 provides a clean separation of the business logic components hosted by WebLogic and the presentation logic components. Developers with strong knowledge of EJB and WebLogic programming build the reusable business components. Developers working on Web services and presentation channels can then leverage and integrate them in the presentation tier.

An important issue is the performance considerations resulting from intertier method invocations and data transfers. J2EE design patterns are an invaluable source of information for avoiding such pitfalls. I recommend Floyd Marinescu's book, EJB Design Patterns, as a source of patterns and best practices for building distributed systems using EJBs.

Simple Use Case
Finally, let's look at a typical use-case scenario. Consider a user accessing a financial institution's Web site. A single sign-on procedure automatically authenticates the user. From this point on, he or she has access to resources according to group permissions. Personalized information such as reports, financial data, and news is provided through WebLogic Portal and portlets.

The portfolio portlet gives the user an instant overview of his or her current assets as well as an updated gain/loss situation. The recommendations portlet displays current recommendations according to the user's profile. The user reviews the recommendations and enters a trade order with a limit condition, thanks to the trading portlet. The user logs off, and the order is delegated to the business-tier EJBs.

At the same time, a trade notification JMS message is sent to the portfolio manager monitoring the user. When the portfolio manager logs in to the application, he or she acknowledges the trade order and another JMS message is dispatched from the client GUI application to the trade processor. After some processing, the trade processor returns a JMS acknowledgement message to the business tier, which in turn translates the message to another JMS message recognized by the FIX engine and dispatches it to it. The FIX engine then packages the trade order as a FIX message and sends it to the broker. After some processing, the broker returns a confirmation message, which is translated in a JMS message and returned to the business tier. A notification is sent to the user on his or her mobile phone.

Conclusion
Over the past year, financial institutions have heavily invested in J2EE architectures for adapting and opening their internal IT infrastructure to the Internet, trading partners, and clients. WebLogic Server has become an essential component of large-scale financial applications and essential services such as online trading or portfolio management. Service-oriented architectures are the logical next step for building highly decoupled service-centric and business process-centric solutions. However, current investments in J2EE should be leveraged, and service-oriented architectures should be an evolution of the J2EE component-based model rather than a revolution. Tools such as WebLogic Server and WebLogic Workshop not only preserve your current investments but also facilitate the transition to service-oriented architectures.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...