Many people equate web-services with SOA and consider it the only
viable option for SOA implementations. Jason Bloomberg disagrees and recently opined regarding "Divorcing SOA and Web-Services"
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
Jason is not the first to say SOA does not equal web-services - far from it, there are many who said that before him. For instance take a look at InfoQ's 2006 interview on Enterprise SOA with John Crupi or our interview with Frank Leymann on SOA where he said
FL: We have to clearly distinguish between SOA and Web Service specifications - sometimes, both are mixed up: SOA is an architecture, Web Service specifications define an interoperable platform supporting a SOA.
SOA is not completely new. Some individual aspects of SOA are used in practice for a long time. For example, take a look at "loose coupling": Enterprises are using reliable messaging technology since decades to integrate applications, i.e. to loosely couple them. Don't get me wrong, there are new concepts in SOA, e.g. concepts resulting from the combination of concepts put together in SOA, i.e. they result from emergence.
Web Service specifications make the corresponding technologies available cross platform. I.e. the corresponding specifications do not invent fundamentally new concepts but define how these concepts and corresponding implementations work in heterogeneous environments. The resulting interoperability is groundbreaking, making SOA real.
So there's nothing new about the fact that web-services and SOA are not one and the same. What is interesting here is that Jason tries to look into the brought us here. One cause it seems are the analyst firms themselves - as Jason points out:
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.
Naturally, Jason also said that ZapThink recovered quite early
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 other culprit according to Jason are the technology vendors themselves:
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.
Jason thinks it is now the time to better separate the concepts and let SOA evolve in higher levels of abstraction Not every one agrees that web-services should be separated from SOA. For instance Frank Cohen agrees that they are separate terms but also thinks that they are closely tied
SOA and Web Services are useful visions to move us from the current XML, Platform, Application, and Service (I call this XPAD computing) into the future. IT has been wanting this kind of interoperability, reuse, and governance for decades, including in efforts like CORBA, OpenDoc, DCE, Client/Server, Web 1, Web 2.0, and Enterprise Web 2.0. Those were all efforts to be able to provide a component architecture where software could be reused to provide an enterprise with a faster time to market advantage and then lastly to provide an enterprise with a better view of the customer.
SOA keeps the WS component idea, focuses on composite applications for business workflows, and loses discoverable service idea for statically brokered endpoints, governance for choreography, business issues, troubleshooting, and Quality Of Service (QOS.)
It is just fine to me that sometimes enterprise architects and technology managers get the terminology of SOA and Web Services wrong.
What do you think? is it a problem that web-services are identified with SOA (and vice versa)?