Wells Fargo's IT Arm Blazes Java, XML Trail

NEW YORK (06/30/2000) - Wells Fargo & Co. has laid the groundwork for one of its most ambitious XML initiatives to date, taking a pioneering approach to the common problem of making legacy data available for new uses.

The San Francisco-based financial services company's information technology arm has built a Java-based middle tier that will use XML to help tie together customer data from multiple sources to create a profiling and referral system, enterprise architect Bob Carasik told the XML DevCon gathering here this week.

At a time when major XML projects are still on the drawing board at many companies, Wells Fargo's project is an example of a flexible multitier architectural approach that companies can use to deliver legacy data to a wide range of client devices or other businesses from a variety of back-end systems, analysts said.

"This is representative of a future mainstream trend, which is basically getting a lot of additional value out of your enterprise applications by leveraging XML to open them up to a much broader audience," said Peter O'Kelly, an analyst at Boston-based Patricia Seybold Group Inc.

Josh Walker, an analyst at Forrester Research Inc. in Cambridge, Massachusetts, said XML and Java are still in their infancies, but they're well suited to each other, since "Java is portable code and XML is portable data."

Part of the impetus for the Wells Fargo project was the need to sell the same products to all the bank's customers in the wake of a 1998 merger with Norwest Bank, Carasik said. For instance, Norwest sold mortgages before the merger, but Wells Fargo didn't.

So Wells Fargo pulled together retail customer data from different sources into a single IBM-mainframe-based DB2 database and built a middle tier, using Enterprise JavaBeans and San Jose-based BEA Systems Inc.'s WebLogic application server to help direct the data between the mainframe and various client machines.

Carasik said he expects that the architecture will allow the company to access other databases and exchange data with other businesses. Wells Fargo has even built privacy attributes into the XML-based profiles so they can be adapted to changing regulatory requirements, he added.

In setting up the new system, one of the key decisions that Wells Fargo faced was how much of the immature XML specification it could use. Carasik said the firm stuck with widely used pieces.

Another key decision was where to transform the data into XML. Carasik said the company opted to do that on the application server, where the tools were better, rather than on the mainframe. That way, it didn't have to spend time and money changing the mainframe's existing transport - fixed-format messages via Open Database Connectivity (ODBC).

"We're more concerned with using our resources to add additional data sources than we are with upgrading the messaging interface to that one database," Carasik said.

Instead, the message delivered via ODBC is wrapped into a Java Database Connectivity interface and shown to a program that Wells Fargo wrote. The program decodes the message and builds a new XML message with the customer profile. That XML-based profile is then sent to a Web server via HTTP.

Wells Fargo sends asynchronous messages from the middle tier to the client via the Web protocol HTTP rather than via Remote Method Invocation. "That's the way you want to build systems that go over an unreliable network like the Internet," according to David Smith, an analyst at Gartner Group Inc. in Stamford, Connecticut.

Also, Carasik said, "if the server interface changes, the client programs reading the XML data don't have to change . . . [because] the data is accessed by name, not by position in the message."