Whoa There: SOA, SOA 2.0, ROA, WOA. An Acronym Too Far?
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. But then Dion Hinchcliff wrote about it (and redefined it) in February this year.According to Dion, the basic tenets of WOA are:
However, as Anne goes on to mention, there's been a recent increase in postings around WOA, both for and against the principles:
- Information in a WOA is represented in the form of resources on the network and are accessed and manipulated via the protocol specified in the URI, typically HTTP.
- Every resource on the network can located via a globally unique address known as a Universal Resource Identifier or URI complying with RFC 3986.
- Resources are manipulated by HTTP verbs (GET, PUT, POST, DELETE) using a technique known as Representational State Transfer or REST.
- Manipulation of network resources is performed solely by components on the network (essentially browsers and other Web servers).
- Access to resources must be layered and not require more than local knowledge of the network.
- It is the responsibility of the components to understand the representations and valid state transitions of the resources they manipulate.
- The service contract of WOA resources is implicit; it's the representation that is received.
- WOA resources contain embedded URIs that build a larger network of granular representative state (i.e. order resources contain URLs to inventory resources).
- WOA embodies Thomas Erl's essential Principles of SOA, though in often unexpected ways (such as having a contract, albeit implicit).
... 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".Anne weighs in on the side against WOA, not seeing a fundamental difference between it and REST. Mike Meehan believes it's a term in search of a foundation and entirely redundant. According to one of the people Mike canvased:
“It reminds me a lot of the attempt by someone to gain some name recognition with the ‘SOA 2.0' concept (which one vendor did try to use and then dropped after it was rejected by the SOA community).”As Mike points out, although David Linthicum believes there is a positive aspect to WOA, "it's still SOA":
Dave Linthicum: "What is changing quickly is that enterprises are finding that the path of least resistance is in essence to build their SOAs on the Web, using Web resources, including content, internet delivered APIs, and Web services. Once there is success with WOA you'll see the same patterns emerging behind the firewall, or SOA. This is similar to the rise of intranet applications after the success of Internet/Web systems."However, Dana Gardner believes that WOA could soon eclipse SOA.
So I’m wondering now whether the window for holistic SOA deployment and value, as it has been classically defined, is being eclipsed. Is it possible that Web interfaces and data disintermediation for legacy applications will be enough? Is it possible that exposing the old applications, and reducing costs of IT support via consolidation and modernization is enough?Dana's definition of WOA does seem similar enough to REST though. So returning to Anne, she points out that Wikipedia doesn't have an entry for WOA (yet): but that's obviously not a good indication of it's relevance. She also reiterates the important point that others have also made over the years that SOA is not about the technology: REST is as valid an approach as Web Services:
... 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:In order to understand where WOA (REST in Anne's definition) might fit in to SOA, Anne points out that difference between SOA and WOA is that the former specifies a system-level architectural style (how to implement your service), whereas the latter refers to an interface-level architectural style (how to expose those services to users).
- A method-oriented interface (e.g., SOAP)
- A message-oriented interface (e.g., JMS)
- A resource-oriented interface (e.g., HTTP)
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.Given the history of DCE, CORBA, DCOM, J(2)EE etc., this is also a very good point. But ultimately where does this leave WOA? Alive and kicking, Pining for the Fjords or DOA? Do we really need another term for REST, or is WOA substantially different?
WOA: One more term the world doesn't need
WOA: Prediction for Industry Analysts
Sounds like a classic case of misuse of acronyms
Acronyms should evolve naturally, not be forced. "Acronymitis" (the desire to increase the number of acronyms out there) is a sign of someone who is a RIP (Really Insecure Person). Creating acronyms for the sake of creating acronyms (or other jargon) is the habit of someone who wants to present themselves as being a master of the material, but actually isn't. The yardstick for being a master of the material is how well you can describe the material to someone with limited or no knowledge of the material. Jargon of any sort stands in the way of communication with those who are not familiar with it, and hence is the resort of those who are not the master of the material. Jargon should only arise naturally by the practitioner, not be created before the topic in question is even in practice.
Climbing off the old soap box now...