WOA wins hands-down over SOA in popularity contest

WOA wins hands-down over SOA in popularity contest

Summary: Everybody likes WOA, distrusts SOA. Does this make WOA enterprise-ready?


Why does Web Oriented Architecture (WOA) have so many dedicated and zealous fans, while SOA gets pounded by endless bad press?

Everybody likes WOA, distrusts SOA. Does this make WOA enterprise-ready?

People simply like WOA a lot more than SOA. At least that's the conclusion reached by Roger Smith in a recent article published in InformationWeek. (And also what I've been observing from other sources.)

But does winning the popularity contest mean WOA is a better option for enterprises?

Here's the case presented for WOA, a blending of Web 2.0 approaches -- services delivered from the Web -- with enterprise infrastructure requirements. As Smith puts it, many top-down SOA projects are too unwieldy, and not delivering, and besides, most employees (read business users) are oblivious to the whole thing anyway. Everyone seems to get WOA, however:

"A growing number of companies are finding that lower-visibility Web-oriented architecture (WOA) developments, spawned through grassroots movements, are a better route to the service-oriented architecture. WOA, like SOA, is an architectural approach to system design, though WOA is resource-oriented rather than service-oriented. What's the difference? While the core SOA design unit is a reusable service that fulfills a distinct business function, resource-oriented services are more limited and data-focused."

So WOA works because its a bottom-up approach that starts small and expands.  Many SOA proponents have argued over the years that SOA needs to have an enterprise focus from the get-go, which can definitely be a showstopper. With WOA, you just go ahead and do it, no matter what the rest of the enterprise thinks.

Cloud computing is the clearest instantiation of WOA, and you can get much of the infrastructure you need from cloud-based services such as Amazon Web Services.

The main advantage cited about WOA is that it's simpler than SOA, and in the process is gaining more enterprise converts. Shades of the long simmering REST-SOAP debate also emerge in this new paradigm as well. There's a discussion of how "a small but vocal cadre of enterprise architects" are making their preference for WOA and REST well known.

The article quotes Steve Bjorg, co-founder and CTO of MindTouch, which offers a Deki Wiki that is now deployed by FedEx, Fujitsu, Gannett, Microsoft, Siemens, the US Army. "By going the WOA-plus-REST route instead of SOA-plus-SOAP, the requirements for extending the application dropped considerably," Bjorg says. "There is no SOAP processing stack with complicated WSDL documents, an SOA registry, and what have you. Instead, someone can easily create an extension to Deki Wiki using any number of computer languages."

There are plenty of professionals out there that have a lot of healthy skepticism of the WOA phenomenon. They see WOA as more hype than substance, and basically a very immature and still unproven technology approach. (Then again, the same could be said for SOA...)

The article concludes that there's a place in the world for both WOA and SOA, since they are complementary architectural styles that both have their specific purposes.

As mentioned previously in this blogsite, SOA may benefit from WOA (and Web 2.0 in general) because it enables business end users to see and experience online services via composite mashups and cloud computing. SOA could be sold as an internal cloud that provides online services inside the walls of the enterprise. In this regard, WOA makes SOA real to perplexed business users.  Plus, enterprise SOA implementations may function as islands of integration that will eventually be assimilated into a larger WOA, whilestill retaining boundaries.

In the meantime, WOA will get the accolades, while SOA will just keep doing the hard work. Sorry, SOA, people just seem to like WOA more.

Topics: Software Development, Browser, Enterprise Software, Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • I could not agree more. WOA is the route to SOA, and, along the way, we

    might just forget about SOA as WOA grows and gets SOA like features. SOA is too hard to understand, and does not lend itself to people just doing it. In the end, we will forget SOA and just use WOA.
    • SOA harder to understand?

      I still don't think i have really understood either SOA or WOA. It looks like most people think WOA is simpler, so it probably is (i do tend to believe the wisdom of the crowds).
      However, last week i read Eric Roch's blog(*) and he pointed at the Amazon Simple Storage Service (S3) APIs. And the difference in complexity is striking; to me it looks like the SOAP API wins hands down. Are there any public APIs that prove the opposite?

      * http://it.toolbox.com/blogs/the-soa-blog/is-woa-simpler-than-soa-26765
    • SOA like features?

      What would those be? Are you confusing SOA with technologies?
  • Free your mind and go WOA!

    Since I'm already quoted, I can't help but add to this discussion. There is a lot of misunderstanding on WOA, its origins, and why people prefer it. Check out my follow up post at http://is.gd/1T9H

    - Steve
  • RE: WOA wins hands-down over SOA in popularity contest

    Amazing article -- all those words and yet absolutely no meaning whatsoever.
  • WOA is a substyle of SOA

    WOA is SOA with the additional constraints of WWW and REST.


    From Nick Gall, the person that coined WOA:

    * Long version: WOA is 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.

    * Shorthand version: WOA = SOA + WWW + REST

    BTW, Since WOA is a substyle of SOA (ie it imposes additional constraints above and beyond those imposed by SOA), you may be interested in our definition of SOA:

    Service-Oriented Architecture:
    * Long version: An architectural style in which certain discrete functions are packaged into modular, shareable, distributable elements ("services"), which can be invoked by consumers in a loosely coupled manner.

    * Shorthand version: SOA = modular + distributable + sharable + loosely coupled

    IMO, it is the addition of the WWW and REST constraints that make WOA easier to grok than SOA.

    The complaints about SOA seem to be driven by fundamental misunderstandings or faulty assumptions.

    SOA is not a technology. It is an architectural style.

    SOA is not SOAP. A technical realization of an SO architecture might use SOAP for consumer/provider interaction, but this is not requisite to being SO.

    SOA is not WS-*.

    SOA does not require the use of SOAP.

    SOA is not SOAP.

    SOA does not require the use of XML.

    SOA is not SOAP.

    SOA does not require an ESB, registry, and XML applicance, or any other tool.

    SOA is not SOAP.

    SOA is typically applied at the enterprise level but that is not requisite. It can just as easily be applied at lower levels of abstraction.

    SOA is a notion created/coined by Gartner (as is WOA) and is pretty basic: the notion of service provider and consumer, the service interface standing separately from the service implementation. That's it. These are the core principles of SO.

    Some vendors and some analysts have confused the space by overloading the SOA term and equating it with specific technologies. To belabor the point, SOA is not a technology and does not require any specific technology.

    By definition, WOA is a form of SOA.

    Oh, did I mention SOA is not SOAP? ;-)
  • RE: WOA wins hands-down over SOA in popularity contest

    You're comparing apples and oranges. SOA and WOA have both their specific use cases. They can even be mixed (WOA with SOAP). WOA is a browser based type of transaction, which presents many security challenges. Also, for long winded transactions, SOA is preferable to WOA (it's easier to manage state in SOA than it is in WOA). The main problem, however, is (as mentioned previously) security.
    • WOA is a specific type of SOA apple -- WOA requires REST

      "They can even be mixed (WOA with SOAP)."

      By definition, one of the WOA constraints is the use of REST.

      SOAP messages can be used RESTfully, but that isn't common and requires ignoring parts of the SOAP semantics (e.g. ignore the "method" that is specified in the SOAP body).
  • WOA "start small and expand"

    And that's often the problem with SOA. It will be solved but SOA is a long-term strategy and in today's market, business need tactical--to-strategic wins - RIGHT NOW.

    Here at OpenSpan, we take existing business processes (that have been established for years on the desktop), wrap them and expose them as services. They just work. It gets the job done.

    IT is right to think SOA but if you do nothing else until your SOA is complete, likely, you'll have little to show for it in 5+ years!

    • SOA != start big and go top-down

      Neither SOA nor WOA prescribe a top-down nor a bottom-up approach. Either is valid for both. Both are architecture styles and as such that style can be applied at whatever level makes the most sense for the given situation.

      There is nothing about SOA that says it must start at the enterprise level. There is nothing about WOA that indicates it is always best to start at the app level.

      I'm a little unclear of the value of taking existing business processes and wrapping them with a services interface. What led you to putting service wrappers around existing components?