Recently I’ve been re-visiting the land of SOA and one question that is coming up a lot is wether we go down a SOAP or REST route to implement SOA.

First it is probably useful to know why you’re using SOA. SOA provides you with a means of linking together components to build processes that more closely reflect your business. Each component is accessible via a set of services. The other benefit is that you can use the various standards to bring legacy components back into play. The one guarantee about IT or software is that you will have an old component somewhere that doesn’t play with the modern world, but in general most systems will have implemented some form of communication.

In essence SOA is applying conventional techniques to a higher level of abstraction, so in this way it is nothing new.

However there has been a “debate” about how you access the services and define their interfaces. For part of this an equivalence between SOA and Web Services has been assumed. Strictly speaking, this isn’t true. SOA can and does use HTTP to allow you to access services, but you could use MQ, JMS or any other applicable technology.

RPC used to be used in a similar manner prior to SOA, however as any admin having to recover RPC services knows, they can be painful to keep up and running.

In this way, REST is only applicable for the HTTP variation of SOA. However REST presents us with a lightweight way of accessing services by using the the Web Architecture to help. We can use the URL and HTTP themselves to implement the service interfaces. This is good for services that need to be accessed by restricted resource devices (embedded systems) .

SOAP on the other hand offers us a much richer if much more complex environment. Using SOAP you can transfer complete objects between systems, as well being able to arbitrarily define objects.

In terms of which one to use, it is possible to combine the two and provide RESTful SOAP services. My current view on design is that SOAP is good provided you are above a certain level of complexity with the work unit that is passed to the services.

The work unit, is basically the object or query you pass to the service to operate on. The classic example of SOA is an Insurance Policy application. The first stage in such an application would be to capture the applicant’s details and then pass them to the first service in a series that assess the applicant, query Insurance vendors and such like. If you’ve sat in a bank while they seem to go through endless screens where they add various options (extra services) to your policy, then this is pretty much what you’re getting. The work unit here is your application, which is a fairly large complex document.

This does mean that we can have “Applications” that are actually a series of services, that can be changed in part or whole without having to build and change monolithic applications.

However let me contrast this with a service that returns the status of a flight, where you just want to know the expected time. The amount of information sent and returned does not really justify a full blown SOAP stack, so in my view would be well suited for REST where I might simply want to GET the data associated with the flight number. This also means that to query this service I only need to have a an application that understands HTTP requests.

This is in contrast to the amount of work you need to create the SOAP environment in J(2)EE or .Net. Which is also a significant factor in which method to use.

I won’t cover some of the other issues here, such as registries, versions, the authentication and authorization or security. Suffice to say going into SOA does require a fair amount of investment in technology, time, effort, governance and training. Not something to be taken lightly.

In summary:

  • If it is a small scale request for simple values, REST
  • If it is a large complex request with many potential participants, SOAP

Other stuff to look at: