Looking for a RESTful SOA Intermediary (Part Two)

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?

Share the Post:
Share on facebook
Share on twitter
Share on linkedin


The Latest

microsoft careers

Top Careers at Microsoft

Microsoft has gained its position as one of the top companies in the world, and Microsoft careers are flourishing. This multinational company is efficiently developing popular software and computers with other consumer electronics. It is a dream come true for so many people to acquire a high paid, high-prestige job

your company's audio

4 Areas of Your Company Where Your Audio Really Matters

Your company probably relies on audio more than you realize. Whether you’re creating a spoken text message to a colleague or giving a speech, you want your audio to shine. Otherwise, you could cause avoidable friction points and potentially hurt your brand reputation. For example, let’s say you create a

chrome os developer mode

How to Turn on Chrome OS Developer Mode

Google’s Chrome OS is a popular operating system that is widely used on Chromebooks and other devices. While it is designed to be simple and user-friendly, there are times when users may want to access additional features and functionality. One way to do this is by turning on Chrome OS