FRAMINGHAM (09/23/2003) - 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, chief technology officer for Lydian Trust, a financial services company in Palm Beach Gardens, Florida. "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.
While an SOA's benefits are easy to digest, the concept still might be hard to swallow. Companies will have to determine what set of software functions are best converted into reusable network services, a process likely to set off political battles over ownership of data, applications and computing resources. Executives must be sold on the SOA concept, which has a poor track record. Also, Web services standards for reliable messaging, security, management and workflow are not completed and are required for an SOA to be considered enterprise-class.
Research firm ZapThink predicts such issues can be overcome, and that SOAs will become the dominant distributed computing approach by 2006. By 2010, ZapThink expects 69 percent of the total enterprise software market to be service-oriented, and that the overall market for products and services that support service orientation will be more than US$98 billion.
The third-try charm
But before the technology is relevant, companies have to choose the business processes they want to convert into services.
"The biggest issue will be looking at our business processes and what applications are tied to those business processes and really pulling out the functionality that can be shared," says Darrell Delahoussaye, portfolio manager for engineering, procurement and construction systems for Bechtel, which is headquartered in San Francisco. "That is a tough one because it requires quite a bit of investigation, and I can guarantee that there will be political issues."
Corporate executives also must be educated and convinced that a Web services SOA won't repeat past mistakes.
Experts say the big difference is that CORBA, DCOM and other approaches were rigid. The services and clients were tightly coupled and the technology proprietary. The services were broken into small, fine-grained bits that required lots of chatter between the client and the service to accomplish a single task.
"With an SOA you don't have to program all the pieces of the puzzle like you did with CORBA," says Jason Bloomberg, an analyst with ZapThink.
At the core of an SOA are three elements that define a networked service: a provider, a registry and a consumer. The provider is the application - although sometimes this application is little more than a snippet of code to perform a basic task, such as calculating sales tax. The provider sends descriptions about itself to the registry, such as information on what the application does and how to connect to it. The consumer (typically another application) uses the registry to discover the existence of various providers and then directly connects, or binds, to those providers.
SOAs are loosely coupled in that services can be connected on an ad hoc basis, and that services and clients can be changed independently of one another. The services have standards-based interfaces and are coarse-grained in that they provide a distinct service or business process, such as the tax calculator or issuing a purchase order.
"If you have a policy system or, say, 20 policy systems, and you don't know which ones you may end up using in a year, you build a policy service that does primarily what everybody needs," says Dmitry Tyomkin, enterprise architect for Continental Casualty Co. (CNA Insurance) in Chicago. "Behind the scenes the service may reroute the request to a legacy system, but tomorrow when we retire those legacy systems it will be transparent for the consumer, it won't need to change its code."
CNA Insurance, which was built through acquisitions, is in the first phase of an SOA to integrate various systems and applications so it can respond better to change and better serve its customers.
Tyomkin says a year's worth of work has taught him that the benefit of an SOA is best viewed from a business perspective.
"You look at your business needs and see how you can dissect your business processes to identify the reusable portions," Tyomkin says. "If you feel there is a significant demand for those processes then you are probably a good candidate for an SOA."
Build, don't buy
An SOA is something that is built, not bought as a software suite, according to experts. However, there are some key pieces of software that must be purchased. First are the development tools from BEA Systems, Borland Software Corp., IBM Corp., Microsoft and Sun Microsystems Inc. to build native Web services applications or create interfaces for legacy applications.
There also are tools from vendors such as Acucorp Inc., Fujitsu Ltd., Jacada Ltd. and Micro Focus Intl. Ltd. that help legacy programs written in languages such as COBOL adapt to an SOA.
"In CORBA, you had to change legacy applications to play, but with an SOA you don't change the back-end applications. You link them together," says Mark Haynie, vice president of enterprise extensions for Micro Focus.
Independent software vendors also are starting to add native Web services interfaces to their products from enterprise resource planning systems to collaboration servers.
Another key element is SOAP servers, with the dominant variety today being Web application servers, although SOAP traffic can be carried by TCP/IP as easily as it can move over HTTP.
The SOA registry typically is supported by Universal, Description, Discovery and Integration (UDDI), a Web services protocol. A UDDI registry, sort of a Yellow Pages of services, lets application components be easily found, called and reused instead of being hard-wired together. Companies such as Fujitsu, IBM, Microsoft and Novell Inc. offer UDDI registries, as do smaller vendors such as Flashline and LogicLibrary. The latter also add features to help developers create, manage and monitor a collection of services.
However, a full-fledged SOA is not just about developing applications as services. Standards for transactional messaging, security, workflow and management to ensure scalability and reliability are needed but are still under development, and in some cases competing protocols are slowing progress. Infrastructure upgrades to middleware also will be needed to handle the increase in XML traffic once services become prevalent.
A crowd of specialized vendors offer to fill those gaps with everything from message control systems, management platforms and XML traffic accelerators. These vendors include AmberPoint, Actional, Blue Titan, Cape Clear, Confluent, DataPower, Digital Evolution, Infravio, The Mind Electric, Sarvega, SeeBeyond, Sonic Software, Systinet, Talking Blocks, Vordel and Westbridge Technology.
"The SOA is an evolutionary step in the adoption of Web services," says Tyson Hartman, a technology fellow and director of .Net solutions for consulting firm Avanade. The long-term benefit is not only easier integration, he says, but a logical method for "deploying a set of services through their lifetime on the network."