X
Business

The SOA with reach: Web-Oriented Architecture

I recently had the pleasure of watching Nick Garr give his take on something he describes as Web-Oriented Architecture or WOA. There are a lot of ways to view Service-Oriented Architecture (SOA) and this particular lightweight vision of SOA is well worth watching. This is because WOA is more of an emerging best practice from the battle-hardened folks in the field than it is from ivory tower architects or the analyst group notebook, which always lends an idea more credence in my book.
Written by Dion Hinchcliffe, Contributor

I recently had the pleasure of watching Nick Gall give his take on something he describes as Web-Oriented Architecture or WOA.  There are a lot of ways to view Service-Oriented Architecture (SOA) and this particular lightweight version of SOA is well worth watching.  This is because WOA is more of an emerging best practice from the battle-hardened folks building software on the Web than it is from ivory tower architects or the analyst group notebook. This always lends an idea more credence in my book.

This is all making folks fall back to simpler and more straightforward methods that just work.Essentially, WOA describes a core set of Web protocols like HTTP and plain XML as the most dynamic, scalable, and interoperable Web service approach.  The only real difference between traditional SOA and the concept of WOA is that WOA advocates REST, an increasingly popular, powerful, and simple method of leveraging HTTP as a Web service in its own right (and carefully devised by the co-creator of HTTP, Roy Fielding.)

An important concept in Web 2.0 is that Web-based software should offers its functionality not only via the browser, but also as open Web services so that it can be mashed up in new and unintended ways.  This takes software from being a mere application and turns it into a true platform.  A great many new online software applications are actually doing this now, even if it's just one-way via RSS.  And it's not just online consumer applications, major players like Salesforce are encouraging API use of their products on the Web and are even creating public directories, like Salesforce's AppExchange or Yahoo!'s new application Gallery, to make sure folks are aware of, and can find, the resulting third-party mashups.

The theory of sharing your application's pieces as Web services is that it allows your functionality and data to be useful to others in innovative ways you won't be able to predict ahead of time. People can take your best features and combine them with others, allowing you to become part of a larger supply chain instead of being limited to your individual delivery channel.  It's an interesting value proposition that the growing mashosphere seems to be validating.  And we shouldn't forget that SOA encourages this exact same view by liberating the silos of data and software in an organization as Web services, making it possible to share and reuse them anywhere inside an organization in a loosely-coupled and interoperable way.

WOA itself is a reflection of the classic Reach vs. Rich argument, in that richness is an outcome of robustness and complexity but cuts down how much reach you have to others, particularly in heterogenous communities.  And the modern SOA technologies and architectures have indeed become a near-morass of complex standards, protocols, and products.  The result is that the present list of WS-* standards is now nearly incomprehensible by a mere mortal. 

SOAP, the most common "true" Web service standard also has mandatory dependency system that can be problematic.  This is something I refer to as the "tyranny of SOAP's mustUnderstand flag".  And it makes it so that if you don't have the exact same set of standards in your Web services stack, you can't even talk to a Web service at all.  This is actually terminal to interoperability, instead of being the intended enabler. 

This is all making people fall back to simpler and more straightforward methods that just work, and hide the protocol complexity in the application state.  As far as REST and WOA are concerned, you don't need anything more complex than HTTP, one of the most scalable, proven, and widespread protocols on the planet, along with HTTP's verbs: GET, POST, PUT, DELETE.  Add some plain old XML to hold your data and state to top it all off.

 

 
Web-Oriented Architecture

WOA itself is a new term out of the Gartner acronymizer but it's an important aspect of something I usually call Enterprise Web 2.0, which on the technical side strongly prefers the simplest, most open, Web-scale approaches.  An important point however is that SOA is not necessarily about Web services at all, but is actually much more about service-orientation concepts like loose coupling and abstraction (see Thomas Erl's terrific eight principles of service-orientation for a complete list).  This means you can do a great SOA with CORBA or even classic sockets.  As long as you follow the basic rules of service-orientation.

And, before anyone gets hot under the collar and writes about how REST doesn't handle enterprise issues like two-phase commit, messaging, asynchronicity, etc, I'll also go on record to state that WOA is definitely not the hammer for every job.  Certain applications, particularly in the high-end of the enterprise, just flat-out require the more sophisticated portions of the SOA stack (and don't forget, WOA is a subset of SOA and is not disjoint, as long as you follow the principles of SO).  For the vast majority of uses, I'll argue that WOA is the most interoperable, easiest to implement, and most highly scalable technique for building great, open Web services that anyone can use.

Forget the acronym for the moment, what would you prefer to use a Web services with?

Editorial standards