When people talk about Web services and Service-oriented Architecture (SOA), it’s usually a good idea to ask them what exactly they mean by those terms. There’s not only a multitude of standards in this space, but also not one, but at least three different architectures competing for dominance, each with their own history, strengths, and weaknesses; those who favor one of them usually have little to no tolerance for others who believe in another one.

I will try to describe what I perceive to be the three most important styles of doing SOA. In this context, my intent is to use the term “SOA” as something that subsumes all of the Web-based distributed computing styles currently en vogue; some use SOA to describe Web services. I take the liberty to declare what SOA means simply because any definition is as good as this one, and I need some sort of umbrella term. (And yes, that means I actually consider REST to be one way of doing SOA.)

RPC-style Web services

First, there is the RPC (Remote Procedure Call) style. This style is rooted in distributed object technologies such as CORBA, DCOM, or RMI; essentially, it takes the same development model, exchanges IDL for WSDL and XML Schema, replaces the data format used to encode messages on the wire with XML (more specifically: SOAP), and uses HTTP as a transport protocol. The fact that HTTP, XML and SOAP are used is nothing more than an implementation detail. If this style is combined with so-called contract-first design, the WSDL becomes visible; in many cases, though, it is generated behind the scenes from some programming language construct (usually an interface or class). The most important construct in this style is the interface. Accepting some rather heavy oversimplification, it would be fair to call this style “WSDL-based”.

Message-oriented Web services

While the RPC style was originally very popular within the Web services community, in recent times there’s been a shift towards the idea of message-oriented (or document-oriented) Web services. With this style, the fact that SOAP and XML are used on the wire becomes more explicit and more visible to the developer; rather than talk about RPC requests and responses, one talks about messages and documents. Intermediaries, as defined in the SOAP processing model, play an important role during processing of messages. Whether HTTP or some reliable messaging technology, such as a MOM system, is used to transport messages from one processing node to the next is considered an implementation detail. It is debatable whether the interface (WSDL) plays a central role in this variant; obviously, though, the message is the most important concept. Recently, there have been attempts to give this style a new name; oversimplifying again, I’ll call it “SOAP-based”.

REST

Finally, there’s REST (REpresentation State Transfer), the architecture behind the Web itself. The key construct in REST is the resource, which is identified by an address taking the form of a URI. Resources support a generic (uniform) interface, in case of HTTP consisting of the verbs GET, PUT, POST, and DELETE. With machine-to-machine communication, the resource representations are usually encoded as XML; it is debatable whether they might take the form of SOAP messages. In any case, the central concept is the resource; this style is also the only one to use HTTP as it is intended to be used: as an application protocol, not as a transport protocol. It is thus not an oversimplification to label this style “HTTP-based”.

In the next three parts of this mini-series, I’ll explore the WSDL-, SOAP- and HTTP-based approaches to SOA, highlighting both advantages and disadvantages.