Opinion: Are we at risk of losing SOA in favour of Web Services?

by Mark Little on Dec 20, 2006 |

We've had lots of debates about what SOA means to different people (thank goodness SOA 2.0 seems to be dying!), what is the exact definition of ESB and how it relates to SOA, SOA versus REST etc, so it's fair to say that SOA is here to stay, at least until the next TLA comes along.

I think we can all pretty much agree that SOA is not purely something that comes in a shrink-wrapped box. However, the central principles behind SOA (services, messages and the triad of producer/consumer/registry) are implementation agnostic (I could use CORBA just as much as SOAP/HTTP). Everything else is almost entirely left to implementation approaches. So UDDI for registry; SOAP/HTTP for interactions; WSDL and WS-Policy for contract definitions. Unfortunately this is only good up to a point: if you are happy living in a Web Services world then you are (almost) covered completely (or will be if you let OASIS and W3C do their jobs over the next few years or so).

However, as I said before, SOA is implementation agnostic and many people want to embrace SOA principles but not Web Services. There are a number of reasons for this, but often the common ones include performance, existing investments and stability of Web Services implementations. There is a lot of effort being expended in the WS-* (r)evolution. Many ESBs now offer Web Services support and use this to justify their SOA credentials (conveniently ignoring the fact that it is just as easy to build non-SOA applications in Web Services as elsewhere).

There has been some good work in OASIS on defining a SOA Reference Model and SOA Blueprints (patterns of use), but so far this has not been taken up by the majority players in either SOA or ESB. Are the big vendors such as IBM and Microsoft really only interested in Web Services as far as SOA is concerned? Are we at risk of losing the bigger SOA picture in favour of Web Services? Is that such a bad thing anyway?

Maybe the majority of users and developers looking to embrace SOA really only want Web Services and it's a vocal minority who complain at the lack of support elsewhere? I believe it would be bad for our industry if we lose sight of SOA and concentrate solely on Web Services. I'm not saying that Web Services are bad (for better or for worse I've been involved in helping their evolution since 1999/2000), only that this is definitely a case of using the right tool for the right job. If we can continue to separate SOA from Web Services, then maybe we don't have to worry about legacy Web Services applications in a few years time.

Editors Note: Mark Little is a new regular news editor for the SOA community on InfoQ.

Related Editorial

Cluster-Wide Caching & Scaling for the Cloud - A Look Inside Resin 4.0

Extend Your Java EE Apps with a Mobile Web Interface

A Unified Mobile Architecture for the Modern Data Center

451 Group Analyst Report: Review of Intel & Mashery API Management Platform

API Management - Application Security Made Easy

Related Sponsor

*Cloud API Management – the Service Gateway Approach
*451 Group Analyst Report: Review of Intel & Mashery API Management Platform

Hello stranger!

You need to Register an InfoQ account or 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

Community comments

Excellent summary by John Harby Posted

A liquid finds its own level by Eric Newcomer Posted

SOA More of a Business Term .... by Jason Lenhart Posted

More SOA, less Web Services? by Mark Little Posted

Re: SOA More of a Business Term .... by Jeevak Kasarkod Posted

The choice of implementation technology _always_ depends on context by Olaf Bergner Posted

Re: The choice of implementation technology _always_ depends on context by Mark Little Posted

Re: The choice of implementation technology _always_ depends on context by Olaf Bergner Posted

Re: The choice of implementation technology _always_ depends on context by Mark Little Posted

Web Services are the thorn in the side of SOA by John Davies Posted

Re: Web Services are the thorn in the side of SOA by Eric Newcomer Posted

Excellent summary by John Harby

One concern I have is where the "baby gets thrown out with the bathwater". Tying SOA to Web Services too tightly seems to be lumping criticism and argument applying to specific specs such as SOAP or WSDL to SOA. Personally, I suspect future SOA fabrics could support multiple protocols, i.e. I could have an orchestration which invokes one service via IIOP/RMI then the next via SOAP then the next via REST. I hope that simply because users are siding with REST as opposed to SOAP that the idea of SOA doesn't get discarded. I firmly believe that SOA can exist in either world.

A liquid finds its own level by Eric Newcomer

That's one I like almost as much as "when all you have is a hammer..."

The right tool for the right job seems to be one of those things the industry can never agree on, since all of us seem to have our favorite technologies that we try to apply to everything.

The big change with SOA that us technologists really don't like is that it isn't about technology. You mention that but of course go on to debate the merits of various technologies.

We have seen a lot of criticism of Web services in general recently, and even Google has stopped supporting the SOAP search API in favor of the Ajax search API.

One of the things that I think has been happening is that SOAP and Web services are maturing - going beyond the initial hype to be used in real projects, and available in many products.

So now we can see what they are really good for because we can really start using them. SOAP and WS-* are finding their place in the world.

Which is not necessarily true of other technologies that are still being hyped unmercifully, such as REST and Ajax. We don't really yet know what they are good for, and since they are not as mature as WS-* a lot of the discussion is theoretical, which we technologists really love (I admit to my own share of the guilt here).

So I take it as a real question - has the industry done the right thing by XML and Web services - especially in the context of what's needed for SOA. I guess I would come down on the side of a qualified "yes" since Web services are the best base for SOA that we have.

I would that say the larger question is whether we can really stop arguing about technology, focus on the cultural changes inherent in SOA adoption, and let the various technologies under scrutiny find their own proper place in the overall scheme of things.

SOA More of a Business Term .... by Jason Lenhart

In reading Eric's post, I cannot help but come back to the idea that SOA is more of a business term. Obviously selecting the the right tool/platform is important from the standpoint of implementation. However, I think Eric brings up an excellent point:

"I would that say the larger question is whether we can really stop arguing about technology, focus on the cultural changes inherent in SOA adoption, and let the various technologies under scrutiny find their own proper place in the overall scheme of things."

I agree with this statement - as it seems the concept of SOA has been around for quite some time (e.t. Parnas ~ 1970s). However there appears to be vast cultural differences within companies that implement successfully and those that do not.

Focusing on the "what" and the "why" seems much more effective for businesses than focusing on the "how" - which is something I am finding in many organizations. Perhaps SOA can offer one single idea:

creating a collaboration or common vocabulary/dialogue between different boundaries and departments to achieve a clearly defined set of interfaces within the business model

This will obviously require the assistance of the business side of the house as creating a digital model of any organization may require changes in order to be effective.

More SOA, less Web Services? by Mark Little

Just to be clear, I'm not saying that Web Services are a bad base for SOA. Quite the contrary. Therefore, I'm in agreement with Eric. But, I do worry that we're at risk of ignoring the fact that SOA is not implementation technology specific. If we do that, then we are at risk of pushing away people who want to adopt SOA but do not (cannot) use Web Services. What I'd like to see if more of a SOA "architecture", a bit like WS-* but not technology dependant, that has bindings to various technologies. For example, they way we've dealt with Security and Transactions in WS has a lot to offer SOA in general, but can't be used directly in, say, JMS deployments or REST, or anything non-SOAP based. Is this the SOA-RM? Or something else completely different?

Re: SOA More of a Business Term .... by Jeevak Kasarkod

I think that is exactly the concern various SOA governance solutions are trying to address.

The choice of implementation technology _always_ depends on context by Olaf Bergner

Well, blindly promoting an implementation technology without paying attention to the specific context it is used in is _always_ a really stupid thing to to. You want platform independence and services decoupled at runtime? Use a MOM for exchanging XML messages. The technology is more mature than WS-*, and I bet it's far easier to monitor.

You have extensive in-house CORBA knowledge and a well thought-out CORBA infrastructure? Why not build an SOA based upon it?

Your SOA architecture requires that certain services be publicly accessible by clients outside your control? Use Web Services or REST as some kind of least common denominator.

I have yet to hear a compelling argument why the principles of an SOA are best realized using Web Services. Platform independence and loose coupling can most certainly be achieved by e.g. standardizing a set of XML messages exchanged via plain HTTP.

To summarize: in my view, the perceived equation SOA == Web Services is pure marketing talk with no rational substantiation.

Cheers,

Olaf

Re: The choice of implementation technology _always_ depends on context by Mark Little

I think the equation 'SOA == Web Services' is just as valid as 'SOA == JMS' and would certainly like to think that continues. Where Web Services win is in their interoperability. SOA+Web Services is a compelling argument if you have heterogeneous environments that want to interact (and those interactions can be internet or intranet based). Sure, you can try to standardise your messages (XML, ASN.1 or something else) between CORBA, REST etc., but as the last 20+ years have shown, that isn't an easy thing to do. Web Services have come closer than anything yet (with the exception of plain-old HTTP). But that doesn't mean that, in a narrower deployment environment, standardising on JMS, CORBA or something other than Web Services, isn't the better way to go. My concern is that the 'SOA == Web Services' bandwagon may be blinding people to the alternatives, which is a shame.

Re: The choice of implementation technology _always_ depends on context by Olaf Bergner

Well, certainly, 'SOA == Web Services' might make sense, _if_ your primary concern is interoperability _and_ your clients are outside your control/have already invested in Web Services. I'm not against Web Services/SOAP. All I wanted to say - and if I'm not mistaken that's what you are saying - is that needlessly limiting your options will likely leave you with a suboptimal solution to your specific problem. That's true with implementing any architectural style, and I can think of no reason why it should be different with SOA.

Re: The choice of implementation technology _always_ depends on context by Mark Little

I think we're in violent agreement ;-)

Web Services are the thorn in the side of SOA by John Davies

Well the title's a little harsh perhaps but SOA is an architecture and Web Services is simply one of several implementations that can be used. When you compare it with the other options it turns out that it's quite a long way down the stack feature-wise. Given a typical enterprise (I have to declare I'm rather investment bank centric) it's difficult to justify a truly Web Services centric implementation. We've had services for years, CORBA did a fine job in the 90s and to be quite honest it's still doing a good job now, even though RMI largely abstracted it in the Java world. With JMS, object serialisation and open wire-level transports like AMQP to cover the non-Java world again it's difficult to see why we bother with classic Web Services tools. They are slow, increase latency, verbose, overly complex and flooded with useless standards.

I guess Web Services are here to stay like Basic. For me there are a few places where it fits nicely but I'll stick to slightly less Web Service centric SOA and leave OASIS to define yet more useless standards.

-John-

Re: Web Services are the thorn in the side of SOA by Eric Newcomer

I would say definitely, if you are building an SOA using a single technology, Web services are not the right choice. I have always said that in fact.

However if you are building an SOA using heterogeneous technologies XML and WSDL provide a useful and unique abstraction that works with about everything.

Again, I believe you are basically arguing for the "right tool for the job" approach, which I agree with - but I would say Web services are more often the right tool than not, at least for any SOA including multiple technologies.

Eric