10 tips on how to prevent business value risk
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Opinion: Are we at risk of losing SOA in favour of Web Services?
Posted by Mark Little on Dec 20, 2006
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.
- This article is part of a featured topic series on SOA
- See more SOA content at: http://www.infoq.com/soa
- Other recent content items in this topic
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
-
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.
-
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
11 comments
Watch Thread Reply