REST is a style -- WOA is the architecture.

Posted by Dave West on Jun 08, 2009

Sections

Operations & Infrastructure,

Enterprise Architecture,

Development,

Architecture & Design

Topics

Internet ,

SOA ,

SOA Platforms ,

Cloud Computing ,

REST ,

Architecture ,

WOA ,

Design

Tags

Web 2.0 ,

Buzzwords ,

Reference Architectures

Dion Hinchcliffe recently offered two related articles that explore relationships between Web Oriented Architecture (WOA) and other technologies. The first deals with WOA and REST; the second looks at WOA and SOA. The main point of the first article: REST is a style and WOA is the architecture. The second article argues that WOA is really a highly complimentary sub-style of SOA and explores the implications of this simple observation.

Hinchcliffe begins his discussion with the recognition that it is REST that first drew your attention:

So you've been reading the many recent articles on the Web about REST, how it's the future of Internet architecture, and you've decided to begin applying some of it in your work. But when you start digging into the subject, REST by itself seems to be about moving data resources from one place to the other over the Internet, not building complete applications. It's unclear (and certainly poorly documented) to you how to situate it properly in context; a fully realized and well-designed piece of software.

He then notes:

You start wondering how REST is used specifically (and strategically) in an application or overall software architecture. In other words, what are the moving parts and rules for applying them. You also wonder what else you should aware of that can be used in conjunction with or to complement REST and make it better. You might even want to know when to break the rules and use other related approaches. This is where something known as WOA becomes useful.

And finally concludes, "So, in short, WOA is much more than REST and REST is the foundational architectural style for WOA."

 

Hinchcliffe defines WOA in two parts: a core that contains REST, URLs, SSL, and XML; and, a "WOA Full" that includes protocols and interfaces (e.g. BitTorrent), identity and security (e.g. OpenID), distribution and components (e.g. Open APIs), and data formats and descriptions (e.g. ATOM). These are organized in a WOA Stack in six levels with (example technologies):

• Distribution (HTTP, feeds)
• Composition (Hypermedia, Mashups)
• Security (OpenID, SSL)
• Data Portability (XML, RDF)
• Data Representation (ATOM, JSON)
• Transfer Methods (REST, HTTP)

This stack reinforces the relationship between WOA and REST, with the latter being fundamental to and supportive of the larger architectural idea.

 

It is important to recognize that WOA has not matured to be an architectural pattern or well-defined framework. As Hinchliffe notes:

WOA is just what developers are doing lately ... a set of best practices for designing Web applications. And it's not a grab bag of approaches and technologies, it's actually a fairly elegant model that works: It's secure, it scales to the Web, it performs, ... is also generally simple to work with, easy to implement, and usually is intuitive once you understand the Web.

 

So how does this style and architecture discussion relate to SOA?

First, according to Hinchcliffe, "WOA is a really a sub-style of SOA that is actually highly complimentary.Further

WOA clearly offers a number of advantages to those doing traditional SOA today. This includes considerably improved service consumption models that are less expensive and time consuming to use as well as unleashing the tremendous power of link architecture to drive information discovery, leverage, and analysis. The profound business implications of open APIs and cloud computing are growing clearer by the week. WOA also provides an excellent on-ramp to access the many powerful new online product distribution models currently available today. Distribution of SOA is a woefully neglected topic and WOA can bring an extensive set of techniques, from syndication to extraordinarily low-impedance Web services.

And WOA - because it incorporates REST as a core technology but is not synonymous with it - offers ... reconciliation of Web services technology from a SOAP-based model to one based on REST."

WOA might be viewed as a means for taking SOA beyond the firewall. Hinchcliffe and his colleague, David Linthicum, suggest:

The biggest story for WOA will probably be its cross-firewall implications for API divisions that monetize SOA and provide scalable, self-service trade partnering capabilities, though the inside of the business will be a big story too.

 

WOA enables SOA practitioners to explore a different set of business scenarios. Hinchcliffe discusses five potential scenarios including; "Information in a SOA becomes crawlable, searchable, and discoverable" and "Open APIs Expose WOA's directly to partners."

Both Unboxing WOA: the 6 Aspects of an Emergent Architectural Style and The SOA World begins considering WOA in earnest should be read for additional insights into the REST, WOA, and SOA triad.

1. Back to top

   Funny how people forget

   by Charles McKnight

   that the Internet is more than just the web or web technologies...

   Reply

2. Back to top

   Re: Funny how people forget

   by Dan Hansen

   I agree. In another blog post he goes on to say "Traditional SOA builds a messaging layer above HTTP using SOAP." I would like to know where that is the tradition. What about JMS or Stomp as apposed to HTTP? In addition, how many organizations using those technologies are using SOAP to define their messages? What about all the other technologies available for creating a SOA? Combined these can provide you with many advantages over HTTP and REST such as EDA and Guaranteed Delivery of messages. Of course, the necessity of these advantages will vary from organization to organization depending on their needs.

   Reply

3. Back to top

   I remember servlets...

   by Guy Pardon

   First we had HTTP and then we had servlets and then a lot more useful things to work with and build web apps.
   
   
   
   So what is the equivalent for REST? Everything I have seen so far makes me think we need to publish (read: program) ATOM feeds, parse raw XMLs and other VERY low-level stuff to get REST things done. Hardly anything I find attractive or useful.
   
   
   
   I hope I am wrong (contradict me please!) but this seems a bit like the equivalent of implementing web applications by writing your own socket library: doing a lot of low-level work that I don't want to care about. Note: I am purposefully exaggerating to get my impression across ;-)
   
   
   
   In other words: please point us to some productivity-boosting REST platform - if such a thing is available...
   
   
   
   Guy

   Reply

• Older >