The five missing pieces of SOA

The high concept of SOA (service-oriented architecture) continues to enthrall IT. Yet SOA’s promise of universal application integration is vague at best, confounding anyone who takes a closer look. Such scrutiny reveals major gaps -- in reliability, security, orchestration, legacy support, and semantics.

Peter Underwood, vice president of software development at brokerage firm Wall Street Access, says his team has had to do some serious thinking up front before planning SOA integration.

“You begin with the idea that [SOA] is bigger than a bread box. In other words, it’s just a framework,” Underwood says. Although SOA “has taken on a life of its own because of Web services” standards, Underwood believes a significant gap remains between Web services’ potential and its current capabilities.

Execs are happy to use Web services for simple needs, such as feeding information to Web-based portals. But complex, mission-critical jobs are another story -- and may demand Web services standards that are still under development. So when is a Web services SOA strategy advisable, and when is good old EAI better? It all depends on what you are trying to do and which gap in Web services’ capabilities you encounter.

Reliability

The need for highly reliable, asynchronous messaging may be the most difficult to meet, at least in the short term. Aiaz Kazi, general manager of business integration at EAI stalwart Tibco, calls this kind of messaging “critical to enterprise-quality integration.”

Sam Boonin, vice president of marketing at Web services infrastructure vendor Blue Titan, says the need for reliability is similar to that which “we’re used to discussing in other computing paradigms. SOA is not quite ready for the utmost transactional reliability -- nonrepudiation, once-and-only-once delivery, and rollback -- but it’s only a matter of time until the standards and implementations mature to meet that requirement.”

In fact, several draft Web services specifications already address issues in mission-critical and lengthy processes. WS-ReliableMessaging, for example, is designed to guarantee that a SOAP message arrives at its destination. WS-AtomicTransaction, WS-Eventing, and several other proposed specifications would define ways of handling complex, stateful, and long-running business transactions. But unlike many security-related protocols (see below), widespread use of reliability standards such as these have yet to be realized.

Until then, says Chris Crowhurst, vice president of enterprise architecture at Thomson Prometric, a provider of computer-based testing and assessment services, “Reliable messaging [for Web services] is quite a burden. But at the end of the day, applications just need to build around it” because of the benefits of the interoperability Web services provides.

For now, “building around it” means coding applications to anticipate and to accommodate error conditions. It also means buttressing point-to-point SOAP interactions with an intermediary -- such as a Web services management broker -- that provides a standardized layer of abstraction. Available from independent players such as Actional, AmberPoint, and Blue Titan, these products enable managers to provide fail-overs and upgrades to software endpoints with minimal interruption to the production systems. (Useful Web services management must work across a range of platforms, which explains the absence of similar solutions from such major vendors as BEA, IBM, and Microsoft.)