ZapThink </>
WOA is Me - Another Acronym? WOA and SOA
Document ID: ZAPFLASH-2008516 | Document Type: ZapFlash
/By: Ronald Schmelzer/
Posted: May. 16, 2008
The problem with IT: Attention Deficit Disorder (ADD). Just when one
concept is finally understood and gaining traction, the pundits,
marketers, and industry standards-bearers come up with a new and
confusing phrase to confound us all. In this iteration of IT?s
fascination with new TLAs (three-letter acronyms for the
acronym-challenged), bloggers and hypesters galore are talking up the
concept of Web Oriented Architecture (WOA). Given ZapThink?s distaste
for old wine in new bottles, we have to ask: is there anything new in
the WOA concept? And if there are new ideas, do they have any substance?
More importantly, if there are indeed new ideas in the WOA concept, how
do these compare and contrast to the SOA concept?
*What is WOA?*
At the time of writing this ZapFlash, there?s no Wikipedia entry page on
Web Oriented Architecture, which is both a sign that there isn?t
sufficient interest to create one (although perhaps the simple act of
writing this might spur an entry), as well as a reflection that the term
is too new to have garnered any sort of consensus definition. However,
over the past year or so there has been a flurry of impassioned blog
writing and research work yielded a number of detailed definitions.
Nick Gall was and early proponent of WOA and defines it as
<http://blog.gartner.com/blog/index.php?itemid=400&catid=31#comments>
?an architectural style that is a substyle of SOA based on the
architecture of the WWW with the following additional constraints:
globally linked, decentralized, and uniform intermediary processing of
application state via self-describing messages.? In his short-hand, he
defines it as the combination of SOA, Web, and REST architectural and
technology implementation styles. Dion Hinchcliffe further clarifies WOA
<http://blogs.zdnet.com/Hinchcliffe/?p=27> as ?a core set of Web
protocols like HTTP and plan XML? to provide a simpler, and in his view,
more scalable, approach to Web Services. He further states, ?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?.
The first question to ask is whether WOA is just the concept of
Representational State Transfer (REST) rebranded. Indeed, Dion
Hinchcliffe makes little distinction
<http://hinchcliffe.org/archive/2008/02/27/16617.aspx> between the
fundamental concepts of REST, which we explored ad nauseum in earlier
ZapFlashes <http://www.zapthink.com/report.html?id=ZAPFLASH-2006712>,
and the concepts of WOA. In his words, ?as far as REST and WOA are
concerned, you don?t need anything more complex than HTTP? along with
?some plain old XML to hold your data and state to top it all off.?
We?ve explored in the ZapFlash referenced above how REST and SOA are
indeed quite complimentary and thus this would apply to Hinchcliffe?s
treatment of SOA and WOA. Hinchcliffe would seem to agree with us:
?don?t forget, WOA is a /subset/ of SOA and is not disjoint, as long as
you follow the principles of [Service Orientation].?
The question about the REST-WOA overlap can best be answered by stating
that while not all REST applications are WOA, all WOA implementations
are necessarily RESTful. Nick Gall, who coined the term, provides
further key insights in a blog posting in which he said
<http://ironick.typepad.com/ironick/2006/08/sam_ruby_thinks.html>, ?I
felt REST was too caught up in religious debates, and Web Architecture
would confuse people, since it was originally oriented toward
user-to-system interaction, not system-to-system interaction.?
Therefore, we can gather that WOA is REST dusted off and applied
specifically to SOA.
None of the proponents of WOA seem to advocate it as a replacement for
SOA concepts, and indeed indicate that it is a subset or style of SOA
implementation. Nick Gall once stated, ?[WOA] describes a subset of SOA
that fits the architecture of the Web?. ZapThink would tend to agree.
Service-Oriented Architecture is an enterprise architecture approach
that is fundamentally agnostic to the method for implementing a Service.
Use of RESTful styles for Service implementation as well as following
specific REST-oriented styles of Service design would be helpful for
those that seek a Web-oriented approach to SOA. Given that, why bother
calling this new concept WOA at all? How about just Web-Oriented SOA?
Users can implement Web-Oriented SOA by following a set of conventions
for defining Services and coordinating their interaction:
* Follow all the precepts of SOA defined by ZapThink as well as
others in the space ? make sure your Services are properly
abstracted, loosely coupled, composable, and contracted
* Every Web-Oriented Service should have an unambiguous and unique
URI to locate the Service on the network
* Use the URI as a means to locate as well as taxonomically define
the Service in relation to other Services.
* Use well-established Web methods (POST, GET, etc.) for interacting
with Services
* Lessen the dependence on proprietary middleware to coordinate
Service interaction and shift to common Web infrastructure to
handle SOA infrastructure needs
*WOA and SOA: Different Levels of Abstraction*
Right now, we?re seeing a lot of breathless adoration of the WOA
concepts, with some stating that it will replace SOA or be the next
evolution of SOA. Neither of these statements are anywhere near correct.
The first glaring problem we see in those statements is that WOA and SOA
define concepts at different levels of abstraction. If we can toss out
the WOA acronym here for a minute and simply talk about Web-Oriented
SOA, I think it all becomes clear. Rather than advocating a replacement
for the ideas of SOA, Web-Oriented SOA simply provides clarity in how to
define and create infrastructure for Services. Just like our earlier
conversations about REST
<http://www.zapthink.com/report.html?id=ZAPFLASH-2007618>, the need for
Web-Oriented SOA arises from the disappointment in Web Services and
current vendor approaches to SOA more so than it arises from a need for
a new architectural form to replace SOA at the enterprise architecture
level of abstraction.
With this in mind, it should be noted that the key requirement for WOA
is a dependence on the Web as a protocol and means for both Service
definition and Service interaction. SOA is necessarily and completely
agnostic with regards to how to define and interact with a Service, but
WOA is necessarily more specific. WOA cannot exist without the Web
protocols, but SOA can. Does this mean that WOA and SOA conflict? No, it
simply means that WOA is more specific than SOA. In other words, WOA is
a more concrete than the SOA abstraction. Hence, we are talking about
different layers of abstraction.
In this way, WOA is really an alternative to Web Services and perhaps
other approaches to Service design, such as emerging mainframe-oriented,
message-oriented, and event-driven approaches that all might mandate
different styles of Service definition and associated infrastructure.
*The ZapThink Take*
A while back, we thoroughly debunked the idea of Event-Driven
Architecture (EDA)
<http://www.zapthink.com/report.html?id=ZAPFLASH-06092004> as a separate
architectural concept. We also took the ill-fated idea of SOA 2.0 behind
the barn and put it out of its misery. Introducing new TLAs are only
helpful when they provide clarity and distinguish concepts so as to make
them easier to understand and implement. Introducing new TLAs
<http://www.zapthink.com/report.html?id=ZAPFLASH-200588> for the sake of
shining up a blogger?s ego or helping analysts create new markets to
peddle their research or events isn?t particularly helpful when we?re
talking about the billions of dollars in IT invested in new innovations
and trends. It?s for this reason that ZapThink takes a particularly wary
eye on concepts that try to rebrand existing, well-worn ideas or split
hairs in concepts that would be better off standing as a single idea.
While the WOA concept does indeed provide deeper insights into how to
best implement a Service and create an infrastructural approach for
scaling Services, we simply don?t see a need to identify this as a truly
separate architectural approach. As mentioned earlier, WOA would be
better represented as Web-Oriented SOA in much the same way that we
derided EDA and indicated that those who wish to take an event-driven
perspective of the world should simply think of Event-Driven SOA. One
could even combine the two and think about Web-Oriented, Event-Driven
SOA as perhaps a counterweight to the Web Services-Oriented, Synchronous
SOA that is all-too-prevalent in today?s so-called SOA implementations.
ZapThink believes that the term Web-Oriented SOA represents greater
clarity than WOA, since it disambiguates the desire to position WOA as
an alternative to SOA as well as more accurately positions the concept
at a lower level of abstraction than the SOA concept. Going forward,
hence, we will prefer the term Web-Oriented SOA over WOA, since it
provides greater clarity. And clarity is exactly what companies today
need to make SOA a reality.
