Resurrecting the distributed app model

The third-try charm Build, don’t buy What to ask of Web services vendors The heart of an SOA

XML and Web services are emitting a singsong chime these days, humming the letters S-O-A. Service-oriented architecture is in the air.

SOA is the latest name for an applications architecture for sharing and reusing code. With today's SOA, applications are built (or retrofitted) with standard interfaces most often based on XML and its derivatives: Simple Object Access Protocol (SOAP) and Web Services Description Language. SOA also defines how those services are located, executed, managed, monitored and secured.

For example, a tax calculator service could be used by shipping, sales and purchasing systems instead of writing, rewriting and updating code within each application to calculate tax. Credit check and fraud "services" could be integrated into a workflow for processing a loan. A purchasing system could be broken into a dozen services that could be used to support other business processes.

Still, SOA is an old concept that is generating new buzz, thanks to the advent of Web services and its promise of open, standards-based interfaces.

"SOA is probably a real nifty marketing term," says John Studdard, CTO for Lydian Trust, a financial services company in Palm Beach Gardens, Fla. "We call it core services. It is a loosely coupled Web services architecture where things can run asynchronously. You have a bunch of disparate services, and you can bring all those services together and call it an application." The company runs about 20 core services that are advertised in a registry and called via a URL to perform specific tasks or business processes - such as credit checks - as part of an automated workflow to support loan processing.

But in fact, an SOA doesn't require Web services. It only makes it more flexible while easing the sharing of services among multiple clients. The lack of those two characteristics caused other SOA efforts to fizzle - most recently the Common Object Request Broker Architecture (CORBA) and Distributed Component Object Model (DCOM).

"The key feature of an SOA is extreme flexibility," says Anne Thomas Manes, research director for application platform strategies at Burton Group. "What you want to do is make all your different application systems act as one huge virtual application that has full access to all the different capabilities in all the different applications systems."

Manes says that is in contrast to traditional application systems. "Today, you have stove pipes in which there is one application, and that application encompasses all its business logic, and no other application in your business has access to that stuff, and so the only way to get to it is to go through that specific application," she says.

Because the SOA is the step beyond point-to-point integration using Web services, it promises easier ad hoc integration of many services while minimizing the typical integration headaches of distributed computing. With an SOA, services can reuse existing software, slash IT administration costs, simplify software upgrades and ease application integration with business partners. And an SOA will run on existing IP-based networks. Additional infrastructure, such as XML traffic accelerators or load balancing, are needed only when services become the dominant means for developing and deploying applications.