In-Depth

Patagon saves old components for new app

• By Rich Seeley
• April 15, 2002

Application Development Trends'
2002 Innovator Awards
Component-based Development
Winner

When it comes to money matters, customers want to know where they stand right now. A successful personal banking and financial Web application must provide customers with up-to-the-minute balances and real-time transactions on a home PC, an office telephone or a cell phone.

That is exactly what Patagon Inc., a Miami-based Internet provider of financial services, set out to provide its customers as it expanded into online international banking.

Patagon wanted to make this transition without losing the investment it had made in the components of its dot-com brokerage Web applications -- not an unusual concern in second-generation Internet projects, according to Gerhard Blummers, program manager at Sanchez Computer Associates, a software and services firm working on this project.

To create the links between existing components in Web applications, as well as connections to stock exchanges, banking systems and other financial networks, Sanchez employed Xpress, a real-time integration engine running on IBM WebSphere and using the messaging technology of IBM MQSeries, Blummers explained.

Making the conversion to full-service online banking with multiple front-end interfaces was not an easy task. Yet the project was mission-critical since Patagon was transitioning from a dot-com brokerage to a full-service, international online bank.

Thus, Sanchez architected and developed a system to attract customers by meeting their needs for immediate financial information and services.

The single, global platform enables customers to conduct financial transactions in a variety of ways and through a variety of channels. The completed application allows customers to complete all their banking business with Patagon regardless of the front-end system.

Middleware architecture allows Patagon to aggregate all customer information to a single point. Even with accounts in multiple countries, the company or its customers can view all transactions involving all the bank's products and services, as well as complete transactions.

Bringing all the components together via Xpress and MQSeries required a multi-layer architecture.

For communications, the system relies on XML with its capabilities for displaying the data from multiple sources in formats that fit the user's hardware and software, whether it is a standard PC and browser, or a cell phone.

The front-end system, which displays the XML in the standard way, has been designed for its interface capabilities. "For the Web page," said Blummers, "it's very simple. JSP deals with the display on the page. For the voice recognition component, the message has to be connected to a voice processor that reads off the data stream."

With back-end legacy systems, linking the components is harder, he added. "The way that we are architected [is that] we have what most people call APIs, and which we call Host Integration Modules [HIM]," he explained. "They actually do the physical translation between the logical message and whatever physical system message is required."

The middleware must be able to take a voice message from a cell phone and convert it into old-fashioned CICS code for the back-end system components to read.

"If we're connecting to an IBM mainframe system running under CICS, we have to effectively simulate a 3270 terminal sending a CICS transaction to that system," Blummers said.

"We have Java and J2EE on the Web," he continued, "but what the middleware/EAI piece does is send an update request to DB2 on a mainframe. This operates on several layers. The service layer will message the HIM layer: 'I now want this update.' The HIM will then convert that message into LU6.2 protocol and CICS format and fire off a CICS transaction, either by MQ or some other protocol. The problem is that the CICS system may require 10 pieces of data to fulfill that message transaction. We have to make sure the 10 pieces of data are there and that they match what we captured at the front end. It's a giant mapping exercise. And that tends to be most of the work."

The Sanchez team did not try to use automated tools to complete the integration of all the components in the online banking system because, in Blummers' experience, the integration requirements are just too complex and one-off for automatic connectors to work. The team used "low-tech" templates that Sanchez has developed and did the custom programming to make all the components work together.

The team faced some compatibility issues in linking different platforms. To make things more interesting, Patagon was implementing the system on Sun Solaris while Sanchez was developing it on Microsoft Windows NT. There were initially object size compatibility issues as the team found that an object developed for WebSphere on NT would not always work on the Solaris version of WebSphere.

While the app tying all the components together was innovative, it required a lot of old-fashioned programming and hands-on software engineering to complete it.

Development Team:

Web CSR Development: Kevin Finch, Victoria Tang, Lin Shan, Sherif Rasmy, Jason Rhinehart, Chi Chi Oguekwe, Cuilin Xin
Web Consumer Development: Gordon Joyner, Piotr Karpiak, Rajeev Gupta, Sebastian Napoli, Will Beckey, Syed Azeem, Balvinda Bahia, Deepta Hiremath, Majeed Khan, Igor Komarov, Gary Roytenberg, Kevin Peters, Raja Chandraseka
Web Development -- Xpress Services: Hema Royyuru, Smita Agarwal, Basavaraj Patil, Bhadresh Doshi, Greg Millward, Sanjeev Gupta,Quansheng Jia, Dan Chisarik, George Kelly, Yuhong Wang, Dimitri Sklyut
Web Development -- Framework: Dan Zugarek, Saurin Shah, Kamal Itigi, Pranav Amin, Subodh Chavan

Above: Kevin Finch, Gordon Joyner and Hema Royyuru

Application profile:

Project: Patagon Brokerage Automation

Purpose: Link multiple front- and back-end systems across several countries, delivering real-time data and transactional capabilities.

Benefits: Conducting financial transactions in a variety of ways and through a variety of channels.

Tools: Sanchez Xpress, IBM WebSphere, MQSeries, VisualAge, WebGain, Visual Cafe, Microsoft Project

Platforms: Unix, Linux, Windows NT

Keane Report:

By developing components that link multiple front- and back-end systems across several countries, this project allows the integration of disparate data and the delivery of real-time data and transactional capabilities. This demonstrates a component-based advantage of "tying into outside data sources and apps." The "use of COTS integration models to reduce development costs in time and dollars for building and testing internal modules" is another attribute of CBD.

In this project, components provided the following advantages:
* Reduced the amount of programming required, thereby reducing development and maintenance costs.
* Faster integration capability, reducing the cost of development resources.
* Improved utilization and efficiency of development resources.
* Portability across hardware and OSs, reducing the need for new hardware.
* Improved reliability and development speed with software component reuse.

The architecture also allows Patagon to update legacy systems on a layer-by-layer basis, moving data in a controlled fashion without platform replacement or automatic data conversion, mitigating the risk of data conversion failure that can result in disruption of service and lost customers. This is a classic implementation of a well-architected, component-based system. The project is an exemplary implementation of utilizing the advantages of component-based development to provide superior value and long-term benefit to customers.

Team Leader: Steve Ruszkowski, Senior Principal Architect, Keane Inc.