Can There Be Too Much SOA?
Can There Be Too Much SOA? - -
April 24, 2006 10:42AM
Web services and SOA aren't the same thing; Web services is one way to get to the goals of SOA. Launched by the Worldwide Web Consortium (W3C), Web services is a set of standards that combine to create the path to SOA, a path that would be standardized enough for all to follow. With Web services, SOA solutions that would likely be as diverse as SOA definitions could converge on a single dazzling path
There's no question that SOA has what Wall Street calls "Mo," meaning "momentum." It's in the trade press, and the business press, and most important in the planning cross-hairs of a lot of CIOs. SOA, which stands for "Service-Oriented Architecture" is just plain hot, but it's also facing a kind of crisis. It's a crisis we've seen before in networking, but still one that may be hard to overcome, and if SOA can't overcome it, the concept may be marginalized.
What is SOA anyway? "Service Oriented" sounds a lot like a marketing slogan for a car wash or an airline. The basic notion of SOA, as it was originally devised, was that applications could be structured as a series of "services," or pieces of functionality, that would then be assembled as needed. Visualize a graphical user interface with a piece of CRM (customer resource management), a dab of Excel, and maybe a shot of data mining all mixed in.
Or visualize a server farm with a piece of functionality here, another there. A transaction can be a piece of CRM, or maybe materials requirements planning, or both. Publish a service, subscribe to it and others to assemble a capability, a business solution. Maybe you want to think of it as a kind of bus, a universal interface or a highway that information flows on. Drive on at Memphis and go all the way to sunrise in LA. Push a data quantity in and spread it as needed through the business.
All That and More
So which one is SOA? All of them. In fact, more than that, so vendors say. The popularity of the concept of SOA, combined with the wonderful vagueness of the term, lends itself to over-promotion. "Service" is a pretty generic term, after all. There's no shortage of jumpers onto the SOA bandwagon, even if their claim to SOA is as vague as the claims you get out of your average dating service. It's very possible that we've never had such a business commitment to a concept that people so broadly misunderstand. But it's not this semantic SOA purgatory that we're fearing; it's the more tangible problem that could arise in what might be the poster child of SOA implementation: Web services.
Web services and SOA aren't the same thing; Web services is one way to get to the goals of SOA. Launched by the Worldwide Web Consortium (W3C), Web services is a set of standards that combine to create the path to SOA, a path that would be standardized enough for all to follow. With Web services, SOA solutions that would likely be as diverse as SOA definitions could converge on a single dazzling path -- a path paved with standards. The concept is so beautiful it almost makes you cry, but save the crying; we may need it later.
Standardization is a funny thing. Achieving the goal of a single approach often requires serving many masters. Every vendor with a stake in an issue has a stake in standards that impact that issue, and these vendors populate the standards bodies with well-funded contributions. There's an old saying that a "camel is a horse designed by a committee." Get the picture?
Web Services and SOAP
Web services, at the basic level, is a way for a client system to run a software module on a server and pass it a message that represents the data that's supposed to be processed. The module returns a message that represents the result. The whole process has been around for decades, and is based on the idea of a "remote procedure call," a way for one computer to run something on another. In Web services, this is done using a protocol called the Simple Object Access Protocol (SOAP).
SOAP is simplicity itself. You send a "service" (the remote module) a message that it processes, and it returns the reply. SOAP software generates the message at the client side, and at the server side activates the software "service" and passes it the message. How easy can you get? Not only that, the format of the message is agreed between client and server and published in an XML schema.
But then standards gurus started to think: How do we address the "service" or the user? Who is this person who's accessing the "service"? Are they allowed to? How about network reliability? Suppose a message gets lost? If we go to the trouble of authenticating a user, should we be able to vouch for that user with other services that need identity assurance? How can we tell if there's enough processing power to perform the service, or where that power might be?
In response to these issues, we've added features, headers, standards for both services and users. All Web services standards start with the prefix "WS-," and we've "WSed" ourselves into a fair flood of new capabilities. It's not that they aren't useful, even necessary. It's just that there are so darn many of them.
Standards Proliferation
Andrew Tannenbaum, an author from "my generation" (which is to say a kinder, gentler time) said that "the wonderful thing about standards is that there are so many to choose from." There's a simple moral here; if you have a bunch of choices of how to implement something that everyone has to agree on a single way to implement, you may as well have not bothered cataloging choices in the first place.
And that's what is happening with Web services, and thus with SOA.
Thirty years ago, the first international data networking standard, X.25, was launched. It was formally debated by international standards-writers, molded and shaped, changed and debated, and eventually settled ... sort of. Many things in X.25 were defined, but many were left to "implementation decisions." Two X.25 devices from two different vendors had about as much chance of going together and working as two builders in the proverbial Tower of Babel, each speaking different languages.
Officials at one health care company told me that they'd counted 71 different Web services implementations, combining different software pieces and standards from different vendors, and that none of them were fully interoperable. Assume that your company picks one, after earnest research. Your supply chain and distribution chain partners follow the process. There are about 14 chances in a thousand that a partner will select your approach. Two partners? 196 chances in a million. Three? Try 2,744 chances in a billion. Get to four and you're about the same range as two different people having the same DNA.
The other problem is that the odds are getting longer, independent of partner count, because the process is adding more and more standards to Web services. Even if there were only a couple of different ways to implement a single new standard, it would double the odds against conformance of everyone to a common interpretation of the total standards set for Web services. Every Web service standard probably exposes a half-dozen implementation interpretations, and many of these are seen as preferring one vendor or another, and each of these preferred vendors is sure to pick their favorite.
IBM, Microsoft, and other companies have recognized the risk of SOA/Web services anarchy, and attempted to create a kind of minimum subset called "WS-Star" (WS-*), a framework of Web services that's supposed to interoperate. Of course, this is viewed by other vendors as a sinister conspiracy to control the Web services market. Not that it would matter; there are plenty of interpretations of even this standard subset of Web services.
Repeating Mistakes of the Past
Those who forget history are condemned to relive it, so they say. The X.25 problems of the past were solved by coercion. Telenet and Tymnet -- two packet data network giants long-forgotten by most -- instituted a program of certification. Equipment vendors could say they were X.25-compatible till they were hoarse, but until they were "Telenet-certified" (or Tymnet, or both), they were barred from connection to the key networks of the time. So maybe we'll have to create certification authorities for Web services to save the universality of SOA.
Who certifies, though? Network operators, including the collection of partners we call "the Internet," simply carry Web services. It's an end-to-end concept, user to user. It may be that a user will end up having to provide the solution for the entire marketplace.
Open Web services -- open SOA -- is like the old concept of electronic data interchange (EDI). Trading partners have, for decades, agreed on formats to exchange commercial transactions for retail orders, shipping and payment.
There's an SOA effort to address EDI, and EDI was standardized by a few key retailers (General Motors, WalMart, etc.) who cut through the debate and told partners to conform or stop doing business.
"WalMart Certified"? In SOA, that may be where we're headed.
April 25, 2006 at 09:41 AM in Web/Tech | Permalink
| Top of page
| Blog Home
