In part one of this article, I discussed how REST separates two different kinds of state information: resource state and application state. Resource state is stored in the persistence layer, while application state is transferred to the client. This state transfer principle is especially important for RESTful SOA, because it frees up the SOA intermediary to be stateless — unlike most ESBs on the market.
Ironically, a stateless ESB wouldn’t work well with Web Services-based SOA, because there is no broadly adopted standard way of putting state information in SOAP, and if you don’t store state information on the ESB, then you want to put it in the message. With REST, however, POST, PUT, and DELETE requests update resource state, and resources transfer application state to the client in representations in the form of hyperlinks. In other words, with REST we always transfer state in messages.
In RESTful SOA, therefore, RESTful Services are stateless endpoints on a stateless intermediary. The RESTful SOA intermediary should enforce a standard URI format and resolve all requests to such URIs into interactions with underlying resources. As a result, a RESTful SOA intermediary presents an abstracted Service fa?ade just as a Web Services-centric SOA intermediary (i.e., a typical ESB) would: through policy-based routing and transformation.
There are several advantages to having a stateless SOA intermediary. Building Service compositions is much simpler than with a traditional ESB, because there are no state issues with composing Services running on multiple ESBs. Asynchronous interactions are straightforward on a stateless SOA intermediary. And perhaps most importantly, it’s much easier to scale a RESTful SOA intermediary, because you can implement multiple instances of the intermediary, and any of them can respond to any request from any client without having to worry about which ESB is keeping track of which client interaction.
In fact, taking the RESTful, stateless approach is essential if you want to put the SOA intermediary in the Cloud. In order to take advantage of the elasticity and automated recovery from failure benefits of Cloud environments, it is essential that all processing on middle tiers of any n-tier application remain stateless. In the case of SOA, that middle tier contains the intermediary.
In sum, we have a lightweight architectural approach to build distributed applications that brings together the best of SOA, REST, and Cloud. What more can a techie ask for?
