Lego, Carrots and Coleslaw

I discovered Jeff Schneider's blog archive about SOA and Lego blocks. He has added some great photos. Unlike some other photos illustrating SOA on the web these blocks on the photo are real lego. Jeff discusses accessibility, recombination, composite applications and peer-oriented systems using the metaphor of lego blocks. He also makes judicial used of carrots, cabbage and coleslaw.

I have discussed some of the advantages and disadvantages of the lego metaphor in my earlier posting Lego and SOA. It has also made an appearance in some videos I have seen and conferences I have attended.

Web Services versus the REST

Despite there being much discussion about the relative strengths on between SOAP Web Services and REST it is not actually that often that you make an explicit decision between the two. Once the die is set you will tend use one or the other. Alternatively it may be self-evident which approach gets used for what services.

The decision to use one technique or another is not made very often. Often such a decision is made in series of smaller decisions over a period time. For instance REST may be chosen to be used for some aspect of some project several times over before it assumes the role of accepted practice in an organisation. Often these decisions are not made in a formal way.

This week my organisation had one of those smaller decision points. The solution architect proposed that we use REST or SOAP Web Services for our services. To define the solution architecture fully we needed to decide which one we going to use.

The case for REST was:

• There would be less processing overhead
• It would a less heavyweight solution as far as programming effort
• Easy for service consumers to understand

The case for SOAP Web Services was:

• The project was already using SOAP elsewhere
• Web Services was a standard and REST was a "architectural style"
• Our partners were more likely to adopt Web Services than REST
• The explicit definition of service contracts in WSDL would be an advantage
• Can deal in standard fashion with reliability and transaction issues
• Better for modelling processes (verbs rather than just nouns)

Other points that were considered

• Our organisation is not particularly experience with either SOAP or REST
• We had used other "service" approaches (neither SOAP or REST in the past)

The decision is not a simply a decision between one or the other. An organisation can adopt neither, both for different circumstances or both in combination. Zapthink advises

… the debate about Web Services and REST is as pointless as arguing whether a
hammer or a screwdriver is a better tool.

W3C discuss a scheme for reconciling the two so that SOAP-based services can be used in RESTful ways.

The winner in this case discussed above was Web Services. This does not commit the organisation to using these technique in the future however this decision will influence future decisions to adopt Web Services in favour of REST. The "horses for courses" approach of choosing the best approach for the application will become less likely as the organisation developers expertise and confidence with Web Services.

Notes:
There is some argument about whether REST is Web Services or not. The use of Web Services Description Language (WSDL) in conjunction with SOAP and not REST suggests that SOAP and Web Services are inseparable. I will use Web Services (capital "W" and capital "S") to describe SOAP based services. Many commentators advocate using "web services" as a description of services developed in REST.

Some REST (Representational State Transfer) include

Daniel Rubio
http://www.webforefront.com/archives/2005/05/rest_-_represen.html

Joe Gregorio, December 01, 2004
http://www.xml.com/pub/a/2004/12/01/restful-web.html

Mark Baker et al
http://rest.blueoxen.net/cgi-bin/wiki.pl?FrontPage