…

 
Well the discussion around Web 2.0 and SOA certainly heated up last week. Dion sent me this interesting……

Bit then I wonder whether you’re saying this because it is a great ‘get of jail free’ card for why SOA isn’t selling to the enterprise and thereby jeopardising the investment in NetWeaver? I know that all the companies who’ve asked me to do something that provides their spin on it all have the same problem. SOA stinks of blue sky and no-one has really figured out how to solve that perception. Being an enabler has always been at the heart of the SOA story, which in turn is only good ol’ integration given a fresh twist and a dash of BPM.

Where is the automatic integration in the new web 2.0 stuff? A lot of closed APIs ought there, regardless of the ‘goodness’ of the service. Assumjing we agree that web 2.0 apps are largely interesting and useful with the added benefit of ultra fast delivery, then do we not in fact have a very strong case for SOA? I think so.

In this case, the argument for me is that web 2.0 gets the user out of a whole bunch of straitjackets that make process improvement a lottery at best. Now we have the means to allow users to work the way really want, assembling apps that are super connected the way that is most effective for them. But — we need SOA at the heart, because this is how we get all those apps connected to our systems in the shortest possible time, without losing the integrations we aready have.

As a starter for 10.

The either/or debate regarding REST and SOA(WS-*, more particularly) has alwasy confused me, as I consider these to be complimentary rather than conflicting technologies.

Most of the benefits of REST regarding scalability, lack of server-side state, etc, can apply to WS-* standards, given you have an actual WS-* stack to work with. Most complaints regarding WS-*/SOA seem to stem from:

1. Lack of available tools.
2. Cost of available tools.
3. Complexity of underlying standards.

#1 and #2 are obvious complaints, but new open source tools and lower-priced product offerings in the SOA/WS-* arena are quickly changing this. #3 shouldn’t really be an issue at all, because any SOA/WS-* stack worth its salt should shield you from the underlying standards in use. The layered approach to WS-* standards is designed exactly for this, in fact. After all, how many web developers spend significant parts of their day trudging through the RFC specifications for the TCP and IP protocols, or DNS for that matter?

SOA Versus REST:

Most of the benefits of SOA/WS-* are not available within REST, making the REST model inadequate for B2B services, enterprise service connectivity, or anything where reliability is of critical importance. REST simply doesn’t offer the capabilities needed to operate critical services with absolute safety and reliability, such as transactions, publish/subscribe message routing, layered security models, consistent interaction scenarios regardless of underlying security model, support for varying security policies and contexts, etc.

While these sort reliability/security features may not be necessary for consumer-facing Web Services, they are of critical importance for B2B operations, “mash-up” services that integrate other enterprise services (airline ticketing mashups such as FareChase are a good example), etc. REST may be suitable for small transactions such as end-user eBay purchases, but no larger organization should risk making millions of dollars in purchases/transactions, gathering critical/time-sensitive data, etc over a REST interface. The risks are just too great.

Regarding the “Simplicity” of REST:

It seems REST is frequently mentioned due to its supposed “simplicity” over SOA/WS-*, but this isn’t really the case. REST relies on the XML and XSD standards, both of which are of significant complexity (especially when character set encodings, HTTP URI encodings, service discovery, etc are taken into account).

There’s a great presentation online that highlights some of the differences between SOA/WS-* and REST (pointing out some of these issues such as URI encodings, etc). It has several highly informational slides discussing these and other points related to the “simplicity” of REST. It is available at:

http://intertwingly.net/slides/2004/devcon/1.html

(The presentation doesn’t get interesting until around slide 9, but points out alot of the complexity issues that can creep into any REST implementation. These issues go beyond simple “complexity”, also affecting reliability and especially security)

Where will this lead?

I personally feel that alot of this debate regarding REST versus WS-*/SOA will soon be irelevant, as most WS-* stack makers have either already added REST interfaces or are in the process of doing so. My company has offered both REST and WS-* stack capabilities in our Packaged Mashup Platform for over a year, for example.