Building SOA your way

A fault line runs beneath the groundswell that began a few years ago with XML Web services and continues today as SOA (service-oriented architecture). True, nearly everyone agrees that XML messaging is the right way to implement low-level, platform-agnostic services that can be composed into higher-level services that support enterprises business functions. Yet, here's also a sense that the standards process has run amok. IBM, Microsoft, and others have proposed so many Web services standards that a new collective noun had to be invented: WS-* (pronounced "WS star" or sometimes "WS splat"). The asterisk is a wild card that can stand for Addressing, Eventing, Policy, Routing, Reliability, ReliableMessaging, SecureConversation, Security, Transactions, Trust, and a frighteningly long list of other terms. Surveying this landscape, XML co-creator Tim Bray pronounced the WS-* stack "bloated, opaque, and insanely complex."

It wasn't always so. Simple forms of XML messaging were succeeding in the field long before any of these standards emerged. At InfoWorld's SOA Executive Forum in May, Metratech CTO Jim Culbert described how his company's service-oriented billing system worked back in the late 1990s. The messages exchanged among partners were modeled in XML and transported using HTTP with SSL encryption -- the method still used for most secure Web services communication today. Seybold analyst Brenda Michelson, who was then chief architect at LL Bean, tells a similar story about that company's early experience with Web services.

Two factors were prominent at the time. First, the Web offered a simple, pervasive integration framework, one later promoted to the status of architecture and assigned the label REST (Representational State Transfer). Second, XML provided a universal way to define services in terms of the data they produced or consumed, rather than in terms of the code that produced or consumed the data. In combination, these factors were -- and still are -- powerful enablers.

Cranking up complexity

How, then, did we arrive at WS-*, which Culbert and others say is a cart that's gotten way ahead of its horse? One theory holds that the heavy-hitting vendors, working closely with key customers and partners, have ratcheted complexity up to a level that only they will be able to sustain. Because those specs are so far ahead of what most users need today, their development hasn't been an organic process driven by well-known requirements. Patrick Gannon, president and CEO of OASIS, the standards body now coordinating a number of the WS-* specifications, reluctantly agrees that users should have been more engaged from the beginning. "I wasn't involved in creating those specs without formal user requirements on the table," he says. "But I'm a pragmatist; the specs are there."

Another view holds that industry heavyweights, who have paid their dues when it comes to security, transactions, and reliable messaging, are indeed qualified to translate their experience in these matters into the language of XML. TN Subramaniam, director of technology at RouteOne, which makes software that streamlines credit management applications on behalf of car dealers, learnt that lesson the hard way. At one point he began drafting his own spec for single sign-on, only to abandon it when he discovered SAML, which his joint-venture partners enthusiastically adopted because all their identity management vendors -- including Netegrity and Oblix -- were supporting it.

"What are the chances," Subramaniam asks, "that five architects meeting every other day will iron out all the possibilities, versus having a committee thinking it all through in great detail with all the vendors on board?"

It's tempting to interpret the tension between these two perspectives as a replay of the cathedral and the bazaar -- or perhaps instead, WS-Heavy and WS-Lite. In that dichotomy, WS-Heavy would refer to the security, reliability, and scalability that WS-* claims to deliver, whereas WS-Lite would mean the speed, simplicity, and agility that attract labels such as REST, AJAX, and RSS. None of the enterprise architects we interviewed for this story has pledged allegiance to either of these camps, though. They're intensely pragmatic people who will do whatever it takes to get the job done, and it's instructive to learn how they are -- and are not -- making use of Web services standards.

RouteOne: securing credit checks

Although end-to-end SSL is often sufficient, RouteOne's Subramaniam has two reasons to prefer the more granular approach enabled by WS-Security. First, it's necessary to digitally sign the credit applications his application transmits, and to do so according to rules understood by service partners. WS-Security defines such rules, although admittedly, and unfortunately, too many of them. One method is to put the signed application into the body of the SOAP message; another is to use SOAP with attachments. In the end, there was no agreement among the service partners, so RouteOne uses both. That's frustrating, but Subramamian would rather have two rules than none.

The second reason touches on one of the deep principles that motivates the design of the WS-* stack: pervasive intermediation. RouteOne is required to maintain meticulous audit logs and would prefer not to have to encrypt all of them. So it's using DataPower's XML router/accelerator to selectively encrypt only sensitive items such as gross pay and Social Security number. Because it's a standards-based intermediary, the DataPower box can straightforwardly modify RouteOne's XML message traffic in this way, and it could be swapped out for another appliance that did the same thing.

When services communicate directly, as many if not most still do, there's no need to define the rules of engagement that enable service intermediation. Today's most visible exemplars of WS-Lite -- Amazon and eBay -- use Web services in a point-to-point way. In that mode there's not much difference between SOAP/WSDL APIs and REST APIs, so it's not surprising that developers who work with these platforms overwhelmingly prefer the REST flavour. But when you do need to flow your XML traffic through intermediaries, SOAP and WSDL suddenly make a lot more sense.

Subramaniam is a pragmatist, however. Plain XML over HTTP, sans WSDL, also plays a role in RouteOne's internal and external affairs. Because it's a no-brainer to put a servlet interface onto an internal legacy system and pull XML data through it, that strategy is used where appropriate. Some of RouteOne's external partners use the same approach, and because "they're making money hand over fist" doing so, Subramaniam can't mandate otherwise. Instead, RouteOne normalizes inbound traffic to SOAP and WSDL in order to enable its expected future use of BPEL (Business Process Execution Language) for service orchestration. Today, partners who don't present SOAP and WSDL interfaces are not competitively disadvantaged. But the tipping point may not be far off.

RouteOne depends on both SAML and WS-Security, and Subramaniam wishes he could use a standard form of reliable messaging, too. "If I don't send a message, we are losing money," he says. Drawing inspiration from ebXML (e-business XML) and JMS (Java Message Service), he specified -- and is now using with partners -- a scheme that guarantees orderly and reliable delivery of messages. But he'd rather it were otherwise and hopes that OASIS will succeed in merging the two proposals it is now hosting: WS-Reliability and WS-ReliableMessaging. This duplication is "really, really bad," Subramaniam says. "I wish we had a common spec so I could dump my stuff and just use it."

• Bookmark this page
• Share this article
  •  
  • facebook
  • slashdot
  • digg
  • Reddit
  • stumbleupon
  • linkedin
  • twitter
• Got more on this story? Email Computerworld
• Follow Computerworld on twitter

• Share
  Share this article

  •  google+
  • facebookfacebook
  • slashdotslashdot
  • diggdigg
  • RedditReddit
  • stumbleuponstumbleupon
  • linkedinlinkedin
  • twittertwitter
• print
• email
• Bookmark