Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


 
 

Looking for a RESTful SOA Intermediary (Part One)

Posted by Jason Bloomberg on Oct 10, 2012

ZapThink has long bemoaned the fact that the big middleware vendors co-opted the SOA story, turning it into an excuse to sell middleware. Even though there's a better understanding of SOA now than ever before, the vendors have largely won the middleware battle. It's hard to find an architect who doesn't believe an ESB is an essential part of any SOA project.

Today, however, there is change on the horizon. Those same architects are getting fed up with SOAP and WSDL-based Web Services. Yes, you can get them to work as part of a SOA deployment, but they're verbose, difficult, and don't provide the product-to-product interoperability that the Web Services standards originally promised. In response, SOA architects are turning toward REST as a lightweight alternative to the SOAPy stuff.

Unfortunately, REST comes with its own challenges. REST is an architectural style for building distributed hypermedia systems, but many techies think it's nothing more than a simpler way to build APIs. True, REST's uniform interface solves some of the knottier problems with Web Services, but the big win for RESTful SOA projects is not only the uniform interface. It's applying the hypermedia approach to dealing with state.



Because Web Services are essentially software interfaces, they are inherently stateless. Therefore, traditional ESBs must maintain state information in their underlying execution environment, typically with threads. This approach leads to two issues: first, composing Services across ESBs is a hassle, and second, you need to write the thread state to a database for long-running processes, and then rehydrate that state when the process resumes.

The RESTful style handles state differently, separating resource state from application state. Transfer state information that must persist or that multiple clients must share to the resources on the server. But for any state information specific to a client, for example, information about many processes in progress, transfer that state information in representations to the client in the form of hypermedia. Ever wonder where the term Representational State Transfer came from? Now you know.

TAGS:

SOA, REST, ESB, Intermediary, Hypermedia


Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap