SOA != Web Services
- Share
-
- |
Read later
My Reading List
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)?
Re: SOA != Web Services
by
Harsha D N
Some definitions ...
by
Kit Davies
;)
Re: SOA != Web Services
by
Julian Browne
No doubt that WS are becoming (is) the de facto standard for SOA implementation though, and far too much consultant-speak and bandwagoning has grown up around the topic for it to have much chance of success in the big corporates.
If it isn't web services then what is it?
by
James Richardson
Or a big ball of xmly webby-servicy messagy-wessagy stuff.
Re: Some definitions ...
by
Arnon Rotem-Gal-Oz
SOA is an architectural style for distributed systems where as web-services is a standard based technology based on HTTP which is built for interoperability.
In addition there's what I call SOA initiative which is a business architecture aiming to reengineer an enterprise using SOA
I wrote about my definition of SOA here
damned by your own words
by
cowardly dragon
...
...
???
Yeah. Can someone else tell me something "new" in SOA? Something that hasn't been done in TIBCO or CORBA or similar previous schemes over the previous decades? SOA maybe adds...platform agnosticism? Maybe?
Re: SOA != Web Services
by
Ilya Sterin
Re: SOA != Web Services
by
Hui Lin
OSGI doesn't seem to be a good solution for SOA, as it requires to have (at least part of) the service implementations available and hook them up in the SOA service implementation.
SOA != Web Services
by
Nati Shalom
There is an increasing class of applications - specifically those that are categorized as XTP (Xtreme Transaction Processing) applications in which SOA in its WS* form, adds no-value due to the fact that the services in this environment are stateful and needs to interact at high speed while keeping the latency low.
There are new emerging frameworks such as OSGI, Mule etc. that provides an alternative SOA approach. The common thing with those framework is the fact that they are POJO driven, light weight and highly efficient in terms of performance and footprint. It is therfore not surprising that those framework are gaining momentum and becomes the de-facto standard frameworks for building high performance SOA.
A colleague of mine, Geva Perry wrote an interesting blog on High Performance SOA
Geva quotes Dave Linthicum from the Linthicum Group ("SOA for the real world"):.
"Making solutions scale is nothing new. However, the SOA technology and approaches recently employed are largely untested with higher application and information and service management traffic loads. SOA implementers were happy to get their solutions up-and-running, however in many cases scalability is simply not a consideration within the SOA, nor was load testing, or other performance fundamentals. We are seeing the results of this neglect now that SOA problem domains are exceeding the capacity of their architectures and the technology in many instances."
I highly recommend looking at his analysis and proposed solution for scaling out of stateful SOA/EDA applications.
Nati S.
GigaSpaces
Write Once Scale Anywhere
Re: SOA != Web Services
by
Arnon Rotem-Gal-Oz
I think Spaces-based solution, with their blackboard architecture are a viable option for scalability within each service boundaries - but this isn't really related to the discussion here.
I guess you can also set up a space as message data grid (as an alternative to a message bus) though I haven't tried it - and it is hard to understand from your response if that is what you are talking about
Lastly, in it's intended/normal use (which does seem to be what you are talking about) a space-based solution is very far from SOA
Arnon
Re: SOA != Web Services
by
Arnon Rotem-Gal-Oz
Arnon
Re: SOA != Web Services
by
Nati Shalom
Nati,
I think Spaces-based solution, with their blackboard architecture are a viable option for scalability within each service boundaries - but this isn't really related to the discussion here.
I guess you can also set up a space as message data grid (as an alternative to a message bus) though I haven't tried it - and it is hard to understand from your response if that is what you are talking about
Lastly, in it's intended/normal use (which does seem to be what you are talking about) a space-based solution is very far from SOA
Arnon i think that your assumption is a bit out of date.
I'll suggest that you would look into the following reference
SBA and SOA which adds more clarify to this topic.
My argument is simple - everyone talks about SOA but very few provides a clear end to end definition on how i can turn my existing stateful tier based application into linearly scalable services. As you can imagine throwing messaging-bus ain't gonna cut-it. I would even argue that it could easily make things worse.
In his presentation Scalable SOA Guy Nirpaz covers at greater depth how you can use Space Based Architecture combined with Spring and potentially OSGI to bridge this gap and turn your existing tier based stateful application into linearly scalable services.
I would be interested to know if had changed your mind slightly after reading this material.
P.S i enjoined reading your paper.
Nati S
GigaSpaces
Write Once Scale Anywhere
Re: SOA != Web Services
by
Ilya Sterin
The root cause
by
Jonas Ekstrom
EAI & EII tries to overcome this problem, but is merely dealing with the symptoms.
SOA on the other hand has nothing to do with application integration (even though the majority of people don't agree). SOA is focusing on the The Root Cause (i.e. to eliminate the application boundary).
SOA is a Utopia where business services maps 1-1 to service implementations. Where business processes make use of those services and where reuse and agility is wanted. All the application boundaries are replaced with service governance based on policies.
How it should be implemented? With Web Service of course!
Re: damned by your own words
by
Floyd Marinescu
thanks,
Floyd
Educational Content
Concurrency in Clojure
Stuart Halloway May 17, 2013
Confessions of an Agile Addict
Ole Friis Østergaard May 16, 2013
Web Development: You're Doing It Wrong
Stefan Tilkov May 16, 2013
Programming The Feynman Way
Ben Evans May 15, 2013
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think