Build Today, Reuse Tomorrow

So what would this mean for XYZ-ABC? If the two firms merged in late 2002 or 2003, they could conceivably solve their integration issues without building some complex, concrete bridge between their two environments. They need only convert their .NET-based assets into Web services and "expose," or make available these assets to their non-.NET other half and even their business partners. Rather than having to scrap one environment for another or build a rigid bridge between the two environments, XYZ-ABC creates loosely coupled Web service components that unlock key areas within each environment and allow them to connect and interoperate freely. It also opens the data within these Web service-enabled sections to future reuse.

Real World Application

Before Web services alters the way entire corporate entities collaborate or combine operations, companies will experiment with the protocol to solve internal software integration problems.

Last summer, Robertson Stephens, the investment-banking subsidiary of FleetBoston, wanted to link RSConnect, the fee-based Web portal created by its e-commerce division, with RobertsonStephens.com, the company's corporate "brochureware" Web site, but a roadblock stood in their way. The e-commerce unit built RSConnect using Sun's Open Network Environment running on a BEA WebLogic server, while the company established its corporate and employee portal on Microsoft's Internet Information Services (IIS), the precursor to its .NET Enterprise Server. To solve the integration problem, "we looked at concepts like shared file systems and databases," says Dirck Hecking, technical architect of the e-commerce division, "but they did not have the flare and speed, and they are a big maintenance nightmare."

The slow financial market afforded Robertson Stephens an opportunity to focus a little attention on the RSConnect-RobertsonStephens.com hub problem. To solve it, Hecking and his team first tried to design their own custom solution using an XML agent server to pass XML documents over the HTTP protocol. The downside was that the team need strong working knowledge of XML. Also "it was pretty proprietary," Hecking says. Meaning potentially high maintenance.
Hecking and his team searched further for a less intense solution. Then they found Simple Object Access Protocol (SOAP). First published in April 2000 and later adopted by the W3C (World Wide Web Consortium) in September 2000, the SOAP 1.1 specification defined a way for applications to call one another over the Internet. By riding on the back of the Hypertext Transfer Protocol (HTTP), SOAP can guide an application, like a company's financial-data software, past firewalls designed to accept HTTP and FTP services requests.

After dabbling not quite successfully with Apache Software Foundation's version of SOAP, Hecking discovered Cape Clear, a small Web services software and integration vendor with a good reputation, while searching developer news groups.

Eager to move the project forward, Hecking quickly put Cape Clear's CapeConnect product to work converting RSConnect's Java-based business logic into Web services that he could "expose" to users on the Microsoft IIS infrastructure. It did not take Hecking and his team long to write the Web services they needed to accomplish Robertson Stephens' goals.

"June was the start date when we starting thinking about sharing between the two platforms," Hecking says. "The rollout happened August 15."

ROI is Power in Right People's Hands

According to Hecking, the return on investment is knowing "you are not going to have developers coding things twice." Once the work of turning an application into a Web services is done, it stands alone as a functioning component that can be called by other applications at any time. More importantly, he adds, because the specification and tools surrounding the specification are easy to implement and use, "you're going to have [Web services] done by the people who own the data. [They] are going to build it out and write it because they know the data sets within their IT departments best."

Going forward, Robertson Stephens plans to define Web Service hubs across its enterprise. "Because we've now built this hub," Hecking says, "we can build more and more things that can be immediately used throughout the firm regardless of the programming language. Each department of the firm is going to basically, over time, develop its own Web service hub and deem what they do as being service-based."

Robertson Stephens is trying to eliminate copies of data now floating throughout the firm because of replication and file sharing servers. They want to replace it with Web services. Because users gain access through an application server layer rather than straight through a database or file system, "you'll never have copies of data," Hecking says, just the data itself.