Service-oriented architectures hold out the promise of reinventing IT as we know it, according to proponents of Web services. With Web services standards such as Simple Object Access Protocol (SOAP) for messaging and Web Services Description Language (WSDL) to identify the content of a SOAP message, users are dreaming up ways to unlock information formerly trapped in legacy systems and share it across their entire IT infrastructures.
Presentation, data and applications will be separated into easy-to-distribute, easy-to-recombine objects, allowing companies to break free of many of the application development restraints they struggled with in the past.
Yet the service-oriented model comes with a daunting challenge. Namely, if Web services are going to change how information is passed and processed in back-end systems, then back-end systems will have to change as well.
Companies such as New York-based insurance firm American International Group Inc. (AIG) and British agricultural giant Associated British Nutrition & Agri-products (ABNA) have undertaken projects they believe will make them Web services-ready in the future.
Needed: Real-time Data
At AIG, Bob Garzotto, chief technology officer for the company's financial services division, has been overseeing the creation of a next-generation data warehouse that uses SOAP as a transport envelope. Garzotto says the real-time nature of the applications that will take advantage of Web services requires that they have accurate, real-time data.
AIG tapped Ascential Software Corp. in Westboro, Mass., to create an enterprise data collection model that transforms all data into easily digestible chunks of XML and connects multiple targets and sources rather than working in a point-to-point fashion.
Using IBM's MQSeries messaging middleware, data from AIG's source systems will feed into Ascential's extract, transform and load (ETL) engine. The files will then be validated, cleansed and compared to previously cached files for consistency. The ETL engine will then generate a flat XML version of the data.
Afterward, the data will be converted to conform to the International Standards Organization's ISO 15022 XML standard so AIG can exchange it with other financial services companies.
"Initially, it's going to take some time to build out the instrument coverage and the messaging structure, but the data will be in a form that any of our users can work with," Garzotto says. "It will allow us eventually to imbed this information into a Web services application."
The project started in April, with the first pilot deployment scheduled for September. Garzotto estimates that it will take two to three years to implement the system inside all of AIG's business units.
Just as AIG plans to enable its Web services development with a uniform data model, ABNA intends to do the same with a uniform messaging model.
In April, ABNA rolled out a uniform messaging system from Sonic Software Corp. in Bedford, Mass. Mysia Benford, IT director at ABNA, says the system will allow the company to get away from Electronic Data Interchange messaging with its trading partners. With the new system, XML messages received from an outside source will be disseminated within ABNA. The company had been using a Microsoft BizTalk-based trading hub.
"We wanted to untie our messaging from any particular application vendor," says Benford. "If you're working application-to-application, it requires the applications to handle assurance and security. It shouldn't be there; it should be in the messaging layer." Now the SonicXQ enterprise service bus will handle the message delivery and secure transport, leaving the applications to perform their primary functions.
Gartner Inc. analyst Daryl Plummer says that in a service-oriented architecture, applications need to be separated from presentation and delivery. "It's about allowing a developer to get things done without having to get into the complexity of it all," he says.
The ultimate goal of Web services is to crumble the IT silos in a given company, and some companies are moving steadily toward that goal.
Erik Sargent, a Web applications architect at Providence Health System, a $3.2 billion hospital consortium in Seattle, has been busily constructing a service-oriented architecture this year. Using a Web services management tool from Redwood City, Calif.-based Infravio Inc., Sargent's development teams have been able to link a user profile management application written using Java servlets with a Web page and credit card service written using Microsoft Corp.'s .Net framework.
"Basically, you replace database calls with Web services calls," he says.
Providence is currently using the tool for its events registration. If an event requires credit card payment, the Infravio tool grabs that payment information, wraps it in WSDL and sends it in a SOAP envelope to the credit card service and profile manager database. Since each action exists as a distributable chunk of data, that information will also be sent to Providence's accounting division.
"The key is to get something in the middle to orchestrate everything," Sargent says. "The problem we were having was that Microsoft really didn't do anything about the Java, and the Java vendors didn't really do anything about the Microsoft platform."
According to Sargent, SOAP/WSDL objects enable the Microsoft and Java applications to share information. Without asking developers to change a line of code, the breadth of those applications has been dramatically increased.
But Providence is far from done. Sargent says the ability to swap data between disparate back-end systems will play a significant role in the hospital consortium's efforts to comply with Health Insurance Portability and Accountability Act regulations.
"We'll need to be able to show who looked at a record, when and why," Sargent says. "Using a Web services model, we'll be able to keep those records constantly updated." To do that, Providence will need to unlock a legacy Cobol-based administration system called Mumps that runs on Unix.
"It doesn't talk to anything," Sargent says.
He says Web services will be used as a distribution method for information headed in and out of the Mumps system.
Common Object Request Broker Architecture (CORBA) objects will be used to pull data out of Mumps. The CORBA objects will then be fed into a Java application that will provide business rules around that data. At that point, the Infravio manager will transform the objects into SOAP objects for widespread distribution.
Barriers Come Down
Toby Redshaw, CTO at wireless device and chip manufacturer Motorola Inc. in Schaumburg, Ill., says his company is also forging ahead with a service-oriented architecture model. "It gives us a chance to dig into the guts of manufacturing processes," he says. "Barriers we've had forever are going to come down."
Motorola has turned to its enterprise application integration vendor, webMethods Inc. in Fairfax, Va., to help wrap manufacturing information in SOAP objects that can then be distributed to other divisions using webMethods' integration broker.
Redshaw stressed the need to create a model for what the enterprise architecture will look like before Web services development begins. He also says that as Web services make data and applications easier to distribute, companies will need to beef up their monitoring capabilities.
"You have to have application and hardware visibility across your entire network," Redshaw says.
That kind of accessibility is particularly critical for systems at the heart of the enterprise. The Denver-based trust services division of Fiserv Inc. relies on two Unix servers for much of the financial tracking and tax reporting it performs as a back-office operations provider to financial institutions.
Both Unix servers run trust accounting software from SunGard Data Systems Inc. in Wayne, Pa. Greg Bakke, Fiserv's director of systems development, says unlocking the servers was crucial to creating a service-oriented architecture.
Bakke found his key in the form of screen-scraping. Using tools from SilverStream Software Inc. in Billerica, Mass., Bakke's staff has been able to pull information from the fields on the green-screen terminals that interface with the SunGard system. It's then transformed into XML data objects that are fed to the SilverStream Java application server Fiserv uses.
"You have to script that entire function and create the workflow, but it's a way to get components that I can then wrap in Web services," Bakke says.
He chose screen-scraping for the job because there didn't seem to be an easy programmatic way to unlock the system.
"We're very much defining the infrastructure we need for a service-oriented architecture," Bakke says. "Every new product we buy now, we look to see if there's a way of exposing things as Web services so that we can reuse them."
Plummer agrees that users will need to think through how their systems will consume and process Web services to make the technology work to its maximum benefit. Although some people loosely define Web services as any business service using Internet transport or XML data, Plummer recommends that users demand more.
"If anybody has a Web services tool and it does not use SOAP, WSDL or UDDI, kick them to the curb," he says. "That's not a true Web services tool."