Perhaps the most aggravating of misperceptions surrounding service-oriented architecture (SOA) in the marketplace is that SOA and Web services are the same thing. This point of confusion is unfortunately quite widespread, affecting architects and developers, consultants and vendors alike. But as with so many issues ZapThink seeks to clarify on a daily basis, the confusion rests upon certain subtleties that are not immediately obvious upon cursory inspection. As a result, it is not sufficient to simply yell definitions from treetops: "SOA is an approach to organizing IT resources to better meet the changing needs of the business!" "Web services are standards-based, contracted interfaces to software functionality and data!" After all, if it were simply about the respective definitions of the terms, the confusion would be long gone. So, why is this fundamental misperception still with us today? And what can we do to resolve this issue and finally move on? A quick look at the history of these two related, but quite separate concepts will help to clarify the distinction.
SOA and Web services get hitched in the first place
The first indication that SOA and Web services are separate things is that SOA has been around for longer than Web services have. Distributed computing approaches from the early 1990s like the Common Object Request Broker Architecture (CORBA) and Microsoft's Distributed Component Object Model (DCOM) were both architectural approaches that abstracted software capabilities in a contracted way that provided a certain measure of loose coupling, offering greater flexibility than architectures that leveraged the tightly-coupled interfaces of other approaches -- in other words, they were service-oriented. And while both CORBA and DCOM each had a certain measure of success in the marketplace, DCOM was unabashedly a single-vendor architecture, and while CORBA was ostensibly vendor-neutral, it was nevertheless vendor-specific in practice
To continue reading for free, register below or login
To read more you must become a member of SearchSOA.com
, as different vendor implementations of CORBA proved to be mostly incompatible with each other.
The story doesn't really get interesting, however, until the late 1990s, when several vendors had two essential realizations: first, that a SOA approach would never provide true agility unless it was implementation-independent, and second, that the relatively new eXtensible Markup Language (XML) would make an ideal messaging protocol, even though its original purpose was as a document markup language. These insights let to a multivendor standards effort that eventually settled on the core set of specifications that provide the foundation for Web Services: the Web Services Description Language (WSDL), Universal Description, Discovery, and Integration (UDDI) and the Simple Object Access Protocol (SOAP, which is now no longer an acronym, as accessing objects is no longer its raison d'âtre).
The early work on the SOA "find-bind-publish" triangle that these three standards enabled focused on business-to-business (B2B) applications, with early visions of a global "green pages" directory that allowed for automated discovery of, and binding to business Web services over the Internet. The problem was, nobody wanted to conduct business that way. It's risky enough picking a plumber out of the Yellow Pages as it is, so who would want to automate the process, adding arbitrary interactions between systems? As a result, this early B2B vision for SOA collapsed, as one small part of the broader failure of the "Web 1.0" B2B eMarketplace trend at the end of the dot.com boom.
Web services take center stage
While the end of the heady dot.com days and the recession and IT downturn that followed put a damper on many standards efforts, the 2002-2003 period actually marked what we might call the golden age of Web services. Vendors realized that the only story that has any hope of generating business in tough times is a cost savings value proposition, and Web services had a great one: lowering the cost of integration. Move from proprietary interfaces to standards-based ones, and think of all the money you can save! And while the standards in those days were far from being ready for prime time, the business case was solid enough for investors at the least, who were still reeling from the crash and looking for new opportunities. And thus, the Web services marketplace was born.
ZapThink, of course, rode this Web Services wave, with our early reports on Web Services Technologies and Trends, XML & Web Services Security, Service-Oriented Management, and Testing Web Services. And yet, while we talked about architecture as early as our February 2002 XML and Web Services Unleashed book, we advised vendors in those early days not to talk about SOA, because the market wasn't ready yet for the more complex, business-centric topic that SOA represented. Instead, the buzz centered on Web Services Architecture, which is basically a standards-based approach to integration.
And yet, we realized back in 2002 one fundamental truth that is every bit as prophetic today as it was when we wrote our Service-Oriented Integration report in June of that year: that while Web services alone can reduce the cost of integration, only by moving to SOA can an organization reduce the long-term cost of business change. In other words, Web services get you the ticket to the ball, but you still have to learn to dance.
The end of the golden age of Web services
As the SOA buzz began to grow, Web services entered their challenging adolescence phase. Support for WSDL, UDDI, and SOAP alone did not guarantee interoperability, and were woefully inadequate to standardize all the complexities of arbitrary system-to-system interactions. These limitations led to two efforts: the Web Services Interoperability Organization (WS-I), who set out to improve the interoperability benefit of the standards, and various follow-on standards efforts, many of which are now lumped into the term WS-* (pronounced "WS star," where the star is an old Unix term that means "anything and everything".) These efforts, naturally, take time, and as the various standards bodies consist mostly of vendors with their own agendas, the entire mess has since become a complex, political quagmire that for all the noise, had delivered precious little true interoperability to organizations seeking to reduce integration costs. As a result, Web services have not yet lived up to their potential, and are now an increasingly marginal part of the SOA story.
In fact, the wheels started falling off the Web services bandwagon when hordes of IT product vendors saw gold in the SOA well. These vendors started slapping Web Services interfaces on their products and calling them service-oriented, an approach that amounted to little more than lipstick on the pig. In fact, Web services interfaces to applications or databases, or even more so Web Services adapters on top of proprietary messaging middleware, do not SOA make.
Meanwhile, ZapThink laid out our business process-centric vision of SOA as enterprise architecture in our SOA Tools and Best Practices and Service-Oriented Process reports, and by 2004, we began advising vendors to focus their messaging more on SOA than Web services. The picture we paint for enterprises today is far more challenging than the relatively straightforward adoption of Web services, because SOA involves rethinking how the business leverages IT in many various ways. Web services are still part of the story, to be sure, but now it has become clear that Web services are not essential for SOA, and furthermore, SOA is not required for Web services.
The ZapThink take
The 2007 story, therefore, divorces Web services from SOA. The services we talk about in the SOA context are at a higher level of abstraction than the particular interface standards that developers use to support the organization's interoperability requirements. Many such services are Web services, to be sure, but many are not. Furthermore, most applications of Web services today take place outside the context of SOA. In fact, many such applications are B2B, circling back to the original vision for Web services (albeit thankfully without the green pages). And yet, most such B2B Web services are simply standards-based application programming interfaces (APIs), devoid of an architecture that would provide the loose coupling, location independence, and business agility that SOA brings to the table. Furthermore, there remain many organizations who are attempting to implement SOA, but do little more than implement Web services instead, ending up with redundant, incompatible, and often unmanaged services that have nothing to do with architecture.
Looking back at the history of SOA and Web services, however, shows a marriage with some interesting twists and turns, because Web services were critically important at bringing SOA to the fore, even though SOA has now grown beyond what Web services can offer. And yet, our work is not yet done, as there remains far too much confusion around the Web services vs. SOA question for this issue to be put to rest quite yet. Perhaps the greatest challenge remaining is to establish the perspective that SOA is really about business process, but not about integration. That challenge will remain as long as vendors hawking integration software cling to the mistaken belief that their software is essential to successful SOA.
