·:[ Integrate This ]:·
• • • • •

Ian Foster, well known Grid Illuminati, wrote an interesting draft paper titled
“How do I access state? Let me count the ways” (Google’s cached HTML version) earlier this year (which somehow evaded by radar), that discusses various approaches to handling state in four alternative architectural styles (or parts thereof) vying to be the base style to make the big picture Grid/SOA visions a reality.

It’s an interesting paper, with a fairly solid introduction to the issue that I agree with almost entirely. It’s also flattering (for the whole REST community, not just myself) that REST is even considered. Unfortunately, the conclusions fall short of the high standard set by the introduction, as REST is misrepresented.

The first indication of problems is the title of the first concluding sub-section; “Implementation Architecture as a Nonissue”. Prima facie this seems questionable, as the study of software architecture tells us that the architectural style one choices is critical in determining the resulting properties of a system. But let’s dig a little deeper;

It has been argued that some interfaces permit more reliable or efficient implementations than others. However, this argument is discredited by the fact that the messages transmitted across the wire in each approach contain essentially the same information.

The emphasis on “essentially” is mine, because the fact is that the messages described earlier in the paper do contain different information, and, as it turns out in this case, that information is critical to fully appreciating REST (and other document oriented architectural styles, though the paper doesn’t get into any of those).

Though there are several claims in the paper that misrepresent various aspects of REST, as well as confusing the Web, REST, and common practice using both, the following from the summary is probably the single most significant misrepresentation, and I’d guess the cause of the belief that lead to the problem described in the previous paragraph. It reads;

In contrast, what we call the State Id and REST approaches adopts a domain-specific encoding of operations, on top of SOAP and HTTP, respectively.

In a RESTful use of HTTP, HTTP provides the operations; there is nothing more to be encoded, domain-specifically or not. Only the data payload – the document representing the state of the job, or whatever it might be – is required, as I previously explained . It’s an odd oversight, because Table 6, which details the RESTful messages, makes no mention of any operation other than the HTTP ones.

I’d be interested in Ian’s comments about how this might impact the paper’s conclusions. I’d also be happy to provide a more detailed response to some of the other claims about the REST approach that I disagreed with, if requested.

In the beginning

For much of the first year or two in the life of Web services – and indeed all of their
history up to that point –
they were about remote procedure calls (RPC); exposing remote APIs across the Internet in order to facilitate machine-to-machine communication and ultimately, business-to-business integration over the Internet.

It didn’t take very long however, for Web services proponents to realize that they needed to distance themselves from RPC and its well-deserved reputation as a poor large scale integration architectural style, due to the failure of systems such as CORBA, DCOM, and
RMI to see any widespread use on the Internet. So, sometime in 2000/2001, collective wisdom in the space shifted towards a preference for “document oriented” services. Vendors quickly jumped on board with upgraded toolkits, and that was that; documents were the New Big Thing.

Unfortunately, the basic architectural assumptions underlying Web services at the time, didn’t change nearly enough to distance Web services from the problems of RPC.

What is “Document oriented”?

Respected Web services guru Anne Thomas Manes
succinctly (and unknowingly, it appears)
describes the differences between RPC and document orientation;

Document style:

<env:Body> 
    <m:purchaseOrder xmlns:m="someURI"> 
      ... 
    </m:purchaseOrder> 
  </env:Body>

RPC style:

<env:Body> 
    <m:placeOrder xmlns:m="someURI"> 
      <m:purchaseOrder> 
        ... 
      </m:purchaseOrder> 
    </m:placeOrder> 
  </env:Body>

The bigger difference is how you encode the message. […]

While the encodings used were certainly different, each with its own not-insignificant pros and cons, what Anne failed to point out is that the RPC example included an operation name (“placeOrder”) while the document oriented example did not. This constitutes an extremely significant architectural difference, as it tells us that Anne’s document example uses a state transfer style, while the RPC example does not.

State Transfer

State transfer styles, which include
MOM,
EDI,
pipe and filter
and others, are characterized primarily by one architectural constraint; all the components expose the same application interface. Actually, in most cases, including those three, the application interface is constrained to providing a single operation that one might call “processData” (it’s actually called “putData” in that pipe-and-filter description). Each server component exposes this operation, enabling any client to submit data to it for processing. In addition, because there’s only one operation, its use is implicit and therefore needn’t be included in the message.

Allow me to reiterate my main point; Anne’s document oriented example above includes an implicit (“processData”) operation.

REST

REST – REpresentational State Transfer – is, as the name suggests, also a state transfer style. One of the interesting ways that REST differs from the others, is that rather than constrain the interface to the single “processData” operation, it allows any operation which is meaningful to all components (referred to as the “uniform interface”). An interesting side-effect of allowing more than one operation, is that it requires messages be explicit about the operation in use, since there obviously needs to be a way to disambiguate messages with the same document, but different operations.

HTTP is the application protocol most closely associated with REST, largely because it was developed to respect many of REST’s constraints. As it related to the uniform interface and explicit operations, HTTP provides a “POST” operation which is an alias for the aforementioned “processData” operation. So, back to Anne’s example again, this HTTP message is semantically identical to her document oriented example;

POST some-uri HTTP/1.1
Host: some-host.example.org
Content-Type: application/x-purchase-order+xml

<env:Body> 
    <m:purchaseOrder xmlns:m="someURI"> 
      ... 
    </m:purchaseOrder> 
  </env:Body>

Moreover, note that if the HTTP operation were different – say, if it were “PUT” instead of “POST” – then the message would no longer have semantics identical to Anne’s original document oriented example. Yes, this means that the semantics of the message are a function of the application protocol being used, unlike conventional wisdom with Web services which suggests that message semantics should be “protocol independent”.

Conclusion

Hopefully this little note helps put in context the architectural relationship between the Web and document oriented Web services. The relationship is closer than it appears in some important ways, yet more distant in others, likely as a result of the fact that Web services began with RPC, rather than with a truly document oriented architectural style. Perhaps spelling this out explicitly, as I hope I’ve done here, will help more Web services proponents realize the importance of the Web to their objectives of integrating systems across the Internet.

When it was first announced last month, I had a quick look at JBI to see if they were making some of the same problems I perceived in the architecture of Web services. I caught a glimpse of figure 3 in section 4.1 where it describes a WSDL-based RPC messaging model, and immediately concluded it was misdirected.

The next week at JavaOne, I ran into Mark Hapner, and we had a talk about SOA, document orientation, REST, and JBI. It was a long, in-depth, thought-provoking talk that left me realizing, amoung other things, that this guy really gets document orientation. I’m not sure he fully appreciates the relationship of it to REST, but he completely understands what it means to do distributed computing with documents. As we were wrapping up, he surprised me by saying that JBI was developed, at least in part, with document oriented and RESTful uses in mind, and that he’d be interested in my thoughts on it. So, hear I am, having a deeper look into JBI.

…

Ok, so having read pretty much the whole thing (minus the APIs and management stuff), I’m not seeing the document orientation friendliness in JBI at all. The container architecture seems reasonable and could support it, but as it also supports the WSDL messaging model – in my opinion, an anathema to integration – perhaps it suffers from the far too common problem of trying to be all things to all people.

I guess I’m with Don Box on this;

I’ve always believed that the Java folks found the sweet spot with the Servlet+JDBC combination back in the 1990’s