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

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.

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.

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?

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

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

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.

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.

I think we're in violent agreement ;-)

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-

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