Bank Finds SOAP Key to Leveraging Legacy Assets

One of Canada's leading banks has found SOAP is not just a protocol, but provides an important tool for leveraging legacy assets in an Internet world. See how ScotiaBank used SOAP to enable their small staff to quickly "integrate" more than 1500 customer Win32/Win2000 clients with a new high-speed Internet system for customers -- without needing to rewrite any custom client software.

Tags: Client, SOAP, Harvison, Applications, Customers, Connections, Upgrading,


Using a combination of standard web services protocols and data formats (SOAP, HTTPS, XML) and tools from .NET, developers at ScotiaBank upgraded WAN connections for more than 1,500 merchant customers -- without rewriting a single line of client code.

Most enterprise developers might not think that upgrading Win32/Win2000 connections from dial-up to high-speed Internet would be an "integration" project, per se.
But just that kind of thinking led one senior ScotiaBank system architect to quickly discover that such an approach would avoid months of custom coding.

Coping with "Rich Clients"
"We had a bunch of Win32 applications for our cash management customers that were built to work with asynchronous dial-up a few years ago," Chris Harvison, ScotiaBank's system architect told IDN from his office in Toronto. Eventually the dial-up network grew to support more than 1,500 of ScotiaBank's biggest mid-sized customers.

"Over time, we enhanced those applications with very rich features for accessing their accounts, exchanging files and we even added a separate security component at our end that handled strong authentication, encryption and data compression for each customer," Harvison said.

In the end, ScotiaBank had a dial-up, secured private network for their customers with most of its intelligence outside the firewall at the customer's customized client. "Inside the firewall, our applications were quite simple to manage and upgrade," Harvison added. "Even our security module worked on a system of APIs against 'thick client' implementations that ran at the customer site."

When customers demanded faster Internet access to their accounts, ScotiaBank faced an architectural dilemma. Because most of the application complexity was on the client side - outside the bank's firewall, if Harvison had upgraded the customer connections the traditional way - using a VPN - he would have faced the unappealing prospect of rewriting client software for most of those 1,500 clients.

Nixing VPN Avoids 1,500 Rewrites
We had tried a VPN approach, running the connections of TCP/IP, but it didn't fly because "our customers were just too different," Harvison said. "Across the board, they were using just about every configuration under the sun." That would have meant every client would have needed a rewrite of some part of their client software, and a different version of the VPN client.

"The rewrite wouldn't buy us any new application features," Harvison told us. "It would have been just to re-establish the client connection to the back-end." So, the hunt was on for an approach that Harvison said "would fix what was broken while leaving the rest alone."

He hit upon the idea of looking at his customer WAN as a series of "components," - applications, access, communications and security. Once he did that, he could separate those elements that needed upgrading from those that "weren't broken." It broke down this way: Access and communications elements needed upgrades; back office applications, security elements (and most of the APIs for each) could be left alone - if possible.

"The customers were quite pleased with the applications and the security, but were dissatisfied using dial-up to get to the host," Harvison said. So, we focused on changing the part of our application that did all the communications.

Implementating a 'SOAP Broker'
"We settled on using XML and SOAP as the message layer and HTTP as the transport." To ensure compatability between the back office applications and the Internet network, ScotiaBank also used Microsoft's SOAP toolkit. SOAP made a lot of sense for us because we talked about using XML RPC as a way to deal with potpourri of client environments and firewalls we have.

The end result, in effect, was a "SOAP broker" that ran on a Win2000 server, with security connections via SSL and HTTP-S. This secured Win2000-based SOAP-based brokering server provided several plusses -- beyond savings of time and money, Harvison said:


(1) It served as the layer that allowed the bank's programmers to "dis-integrate" and "re-integrate" the bank's legacy application and existing challenge/response security applications with the customer's Internet access;

(2) Set in place benefits for future Win32 client upgrades. " In the Win32 client, all the communications, encryption and compression was encapsulated in our APIs, which were common across cash management applications. The new SOAP broker could switch the applications doing just the dial-up part, and change that over to support an Internet connection," Harvison added. We could affect changes to our API set for the core security and applications only when we need to in the future.

(3) Neither the Win32 clients nor legacy applications had to pay attention to the message contents. "We treated the body of the message as text, and inside the XML tags defined and used normal SOAP headers. But, we didn't attempt to go field-by-field to create a new message. All we needed to worry about was creating files to write code to move the files through HTTP, rather than the asynchronous (dial-up) protocol we used to use."

SOAP's Promise: End-to-End Problem Solving
In summary, Harvison draws a distinction between future visions of "Web Services" and tactical solutions that can be built today using some of the tools and standards in place.

"We took a very specialized problem and while it's not considered a web service, it is a picture of how you can leverage the assets you've already built and just fix what's broken. That approach, whether it's what people call a 'Web service'or not, will have lots of appeal for developers and system architects."

"The real promise in SOAP and other web services standards is in integration as a means of end-to-end problem solving throughout an application," Harvison said. "From that point of view, I don't think we're stepping out that much," he added. "All we're doing is supporting the same message structure we had before through a different pipe using HTTP and XML.

Tips for Applying the Solution
A few tips for scoping out whether you can use Scotiabank's approach to upgrading legacy remote client connections:

1. The applications don't have a lot of back-and forth across the network. If you have 100 transactions, let's say, you don't treat them one at a time. You get them in a batch or a continuous stream. "Chunky not chatty" is how Harvison describes the traffic.

2. Your network's security component (authentication, challenge/response, etc.) are centralized and can be modified by running DLL updates or other remote client installs.

3. If you have a well-defined message format, SOAP and XML should allow you to avoid having to make complex changes or monitoring of the message body by simply putting the body inside a SOAP message.




back