Blogger: Anne Thomas Manes
Yikes! The "WOA" term (Web Oriented Architecture) has popped up again. Nick Gall first introduced the term in late 2005 at a Gartner Summit. He described it as a subset of SOA that embraces the principles of REST and W3C's Architecture of the World Wide Web. No one really picked up on the term at the time. I suspect it was drowned out by the Web 2.0 hype.
But then Dion Hinchcliff wrote about it (and redefined it) in February this year. And now there's been a flurry of discussion about the term, starting with a post on ZDNet by Dana Gardner in early April hailing WOA as the savior for SOA. Dion followed up with another article on ZDNet recounting Web 2.0 success stories and implying that SOA might be more successful if it focused on WOA instead. But the pundit community has reacted poorly to yet another "xOA" acronym. Mike Meehan at SearchSOA summarized the discussion nicely and asked if WOA brings anything new to SOA. The same day Dana Gardner published a second article on ZDnet entitled "Enough with WOA". And just last week the ZapThinkers weighed in on the discussion, pointing out that SOA and WOA are different levels of abstraction, and proposing yet another term, "Web-oriented SOA". (Please, no!)
Personally, I don't see any value in the WOA term. I don't view it as significantly different from a RESTful style of building services, but Nick provided some additional reasoning behind the term in a post from August 2006, indicating that the W3C Web Architecture adds some additional constraints.
Dion's revised definition seems to miss Nick's subtle distinction between REST and WOA. Dion's definition is essentially REST, and I don't see the point of using multiple terms for the same thing. We already have way too many terms:
- Tim Bray calls it "Web Style".
- Leonard Richardson and Sam Ruby call it ROA (Resource Oriented Architecture) in their book on RESTful Web Services.
Note that ROA has an entry in Wikipedia, but WOA does not. No doubt someone will rectify the situation soon and ensure that the term "WOA" is formally defined and remains to confuse us all.
I find it amusing that Dion's Web 2.0 Success Stories article was indirectly in response to my post calling for SOA success stories. Advocates of WOA/ROA/WebStyle/etc claim that development of services using simpler technologies such as POX (plain old XML) over HTTP will facilitate SOA success. But as I've recounted before, SOA is not about technology. Using REST rather than WS-* isn't likely to improve the success rate of your SOA initiative. Our research makes it clear that the primary impediment is adoption (i.e., getting the business to buy into the initiative and sponsor development of services).
And actually, the most important thing to understand from a technical perspective is that a service should support access via multiple styles of interface. It should enable an application to interact with it using whatever means it wants:
- A method-oriented interface (e.g., SOAP)
- A message-oriented interface (e.g., JMS)
- A resource-oriented interface (e.g., HTTP)
As the ZapThinkers said, SOA and WOA specify different layers of abstraction. SOA specifies a system-level architectural style (i.e., how to implement capabilities so that they can be consumed by many applications). WOA refers to an interface-level architectural style (i.e., the means by which service capabilities are exposed to consumers). WOA (aka REST or ROA) advocates a resource-oriented interface. (Note, though, that many folks interpret WOA simply as POX over HTTP, which may actually support a method-oriented interface rather than a resource-oriented interface.)
SOA is about services at a conceptual level -- not about any particular technology, interface style, or protocol. You should be designing your services for the long-term. It's highly likely that the technologies that are all the rage this year will fade away into obscurity within the next five years. A service encapsulates a capability and makes it available to application consumers through one or more interfaces/protocols. Be careful to maintain a clear separation of concerns between the service implementation and the interfaces used to expose it. Chances are high that you will need to add additional interfaces over time.