Paving The Way For Web Services

Service-oriented architectures let companies lay the foundation for software that is fast to write, easy to integrate, and runs on a range of platforms.
This year, the Hartford developed an application built with a service-oriented approach meant to encourage small, independent insurance agents to submit business to the Hartford for quotes. The app cuts across a variety of IT systems, including mainframes and Unix servers, and software such as BEA Systems' WebLogic application server, IBM's WebSphere MQ messaging software, Oracle databases, and business apps from Siebel Systems.

When the company made apps from these systems available on the Web to help insurance agents decide how to classify their customers and assess risks, using the software required no specialized knowledge from agents other than how to reach the Hartford Electronic Business Center portal via a browser, says Jim Ruel, senior VP of small-business insurance.

At EXP Pharmaceutical, the company can reuse rules on particular drugs, which may be locked in one large application to be available across many applications. EXP has some 30,000 rules or policies tied up in its applications that govern how expired drugs are handled and accounted for. To keep applications in step with rapidly changing drug compositions and disposal procedures, the company is implementing a service-oriented-architecture approach that lets applications adapt to those changes.

By making the rules generally available to other applications, the approach could let EXP "build intelligence back into our applications" and produce new software at a much faster pace, Siler says.

So how is a service-oriented architecture built? An SOA layer can be built atop much of the existing software infrastructure. Implementers may follow whatever standards they choose--none is specified at this point--but most parties agree it's best to follow Web-services standards such as XML; the Simple Object Access Protocol; Web Services Description Language; and Universal Description, Discovery, and Integration. It doesn't matter what brand-name software or hardware underlies the standards, provided they make themselves accessible through Web-services interfaces.

Service-oriented architectures help build Web services in four ways:

The way IT systems talk more closely resembles communication over the Internet

Most users choose to adhere to Web standards

Applications work asynchronously--one doesn't need to know the other is available to query it for data; the message is stored and forwarded when the system is available

Systems are loosely coupled--one doesn't need to know the details of connecting with another, if they're on TCP/IP networks

Service-oriented architecture is not so much a new, well-defined technology as a software layer above applications and middleware, implementing a set of connectivity standards that easily translate to the Web, says Shawn Willett, an analyst at market-research company Current Analysis. They're usually part of a company's internal computer systems. But more companies are finding that what works for tying one department's applications to another can be extended to integrating the software of parties outside the company's firewall.

Service-oriented architectures mean that the latest application doesn't need to know very much about the existing software infrastructure. It doesn't matter whether an app is running on a Windows, Unix, or Linux server.

One question IT managers raise is whether companies should build SOA software or buy it. IBM, one of the biggest proponents of this type of software design, sells proprietary message-passing software under its MQ brand name. Also under debate is whether companies require an "enterprise service bus" to pass messages from one software system to another. IBM, Tibco Software, and Sonic Software, a unit of Progress Software, say users need it--and they all offer one as part of their product lines.

Charles Stack, CEO of Flashline Inc., a maker of software that manages other software components for development projects, says buying into those products risks incompatibility should the industry agree on a standard. IBM and Tibco's service buses are based on proprietary messaging systems, and Sonic's is based on the Java Message Service, a standard that gets implemented various ways. No two JMS services function the same way and, consequently, don't easily talk to each other, he says. "Wait for a standard to emerge," Stack says, before making it part of your service-oriented architecture.

This story was updated Aug. 2, 2004, to reflect that Flashline makes software that manages other software components for development projects.

Editor's Choice
Brian T. Horowitz, Contributing Reporter
Samuel Greengard, Contributing Reporter
Nathan Eddy, Freelance Writer
Brandon Taylor, Digital Editorial Program Manager
Jessica Davis, Senior Editor
Cynthia Harvey, Freelance Journalist, InformationWeek
Sara Peters, Editor-in-Chief, InformationWeek / Network Computing