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.
About the Author
Rich Seeley is Web Editor for Campus Technology.