Tracking change and innovation in the enterprise software development community
Terracotta:
Scale your
Apps w/ease
Offload the DB:
Learn More!
TargetProcess:
Plan, Track
Succeed with
Agile PM tool.
Free Download!
Tools to get
Visual Studio
2008 Projects
Under Control
Testing Tools to
Support Agile
Software Delivery
Whitepaper
Posted by Arnon Rotem-Gal-Oz on Jul 17, 2007 04:07 PM
Many people equate web-services with SOA and consider it the onlyPerhaps 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 alikeJason 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
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: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.
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.
Service Quality and Validation eKit
Testing Tools to Support Agile Software Delivery
High Performance Messaging: Tuning and Scalability How-to Guide?
eBook: Key Strategies for SOA Testing
The Agile Business Analyst: Skills and Techniques needed for Agile
http://www.infoq.com/news/2006/12/soa-web-services-discussion
I was one of the many people who was under the impression that webservices are SOA. But when I started understanding what SOA is and the amount of buzz words that are there in the SOA dictonary, I was really overwhelmed. It would really help if somebody could demonstrate how we can implement an SOA without using web services! Haven't come across such an application. Wonder if somebody has done that...a case study might help clear up this confusion!!
Just to help us along a bit, could we start by defining "SOA" and "Web services"? Form an orderly queue, please. ;)
I don't have a case study handy, but I've used JINI for SOA before. It's not for the faint-hearted, and you certainly don't get the rich support, deployment and governance tools you'd get with a vendor product, but it's a very elegant solution. REST and CORBA spring to mind as obvious alternatives to WS. 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.
It could just be meaningless vendor spout. Or a big ball of xmly webby-servicy messagy-wessagy stuff.
In a nutshell I would say that 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
"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." ... ... ??? 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?
Web Services is just a way to create a loosely coupled architecture. SOA is about loosely coupled services != "Web services". I think a very compeling SOA example is OSGI, just take a look at the eclipse platform.
I think SOA is the marketing buzzword for the next generation of system integration. Web Services is the most commonly used communication mechanism behind SOA, due to the rich amount and maturity of Web Services based industry standards and products available in the market. 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.
While i think that many of technical folks are in violent agreement that WebSerives and SOA are not necessarily the same thing, the question: what is the alternative approach remains open IMO. 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
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 also implemented SOA on top on messaging infrastructure Arnon
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
Not sure what you mean. A part of the implementations available, which SOA architecture doesn't have a part of implementations available? I guess I'm misunderstanding the use case you're talking about. OSGi allows for discoverable autonomous services and for the most part SOA is about a distributed loose coupled architecture. Though physical distribution qualification is not a must. You can have a perfectly good SOA architecture on the same JVM.
SOA is about questioning the Application as the package and boundary for business automation and system implementation. Applications are silos of functions and information which cannot be easily modified when the business changes. IT and Business doesn't align very well due to the Applications. 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!
hi cowardly dragon, would you be so kind as to use your real name? We do not condone aliases on InfoQ threads. thanks, Floyd
Thanks for making this post, I see this confusion in discussions quite frequently.
Michael Mah analyzes the development process in 5 companies: 2 Agile (one of them BMC) and 3 classic. He presents the factors which contributed to the success of BMC's Agile adoption.
In this interview filmed at RubyFringe 2008, Tom Preston-Werner talks about how both Powerset and GitHub use Ruby and Erlang, as well as tools like Fuzed, god, and more.
David Laribee discusses the purpose of ALT.NET, its mission and future.
Ruby on Rails has become a popular Ruby framework for creating web applications in recent years. An aspect of creating a web application is the need to repeatedly create the same base functionality.
Steven Haines talks about tackling web application performance tuning by proposing a method called wait-based tuning.
Shaw and Fowler talk about the need for a new relationship between the business department and the IT department. Studies have shown that projects mostly fail due to miscommunication between the two.
In this article, Jim Webber, Savas Parastatidis and Ian Robinson show how to drive an application's flow through the use of hypermedia in a RESTful application.
Eccentric artist turned overnight anti-celebrity, Giles Bowkett captures the heart and soul of RubyFringe as he demonstrates his revolutionary Archaeopteryx MIDI drum pattern generator.
17 comments
Reply