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.)
On the other hand, as Dan Foody, CTO of Web services management vendor Actional, notes, “Not every problem requires the same
kind of reliability.” Those that must be ironclad tend to be asynchronous, long-running transactions with many interdependencies
such as complex financial transactions. For less demanding jobs, SOAP over HTTP works fairly reliably -- particularly with
simple, synchronous interactions.
Rajan Jena, an enterprise architect at Bristol-Myers Squibb subsidiary Oncology Therapeutics Network, uses both conventional
messaging-oriented middleware and Web services in his company’s integration infrastructure. He says that messaging solutions
are appropriate when transaction volume is high and is transmitted in batches. On the other hand, Web services are best “when
volume is low -- but it has to be totally real-time.”
Security
Authorization, authentication, and encryption raise a serious red flag for IT managers contemplating Web services-based integration.
Traditionally, access control has been a matter of requiring a log-in and authentication. In the distributed Web services
world, where components of one application might easily go off and talk to components that live in different domains, keeping
disparate but interconnected systems secure is a far more complicated problem.
E-mail
Printer Friendly
Reprints
(InfoWorld) - In the litigious world we live in, deploying a unified communications platform in your enterprise could...
