Application Platform Strategies Blog

WOA, ROA, SOA: When will it stop?

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.

MVC Matrix and the RedPill

Blogger: Chris Haddad

In the near past, Java Servlets, ASP-Classic, and Perl scripts were the truth for web application development. Developers were beholden to HTTP name/value pairs and generated HTML pages via page templates. In 1996, I had a meeting in Redmond with a Microsoft lead Program Manager for ASP Classic. I mentioned that ASP Classic did not enforce a correct separation of concerns between page layout, actions, and business logic. I was thrown out the door and exiled from Redmond for ten years. During my exile, I built intranets with various technologies including ASP Classic and COM, ASP.NET and C#, Apache Struts and Java Server Pages (JSP), in-house developed widget libraries, and DHTML and JavaScript. During my journey out in the cold, I found a sense of elegance missing from all solutions.

 

Over the years, best practices morphed from tightly coupled page templating to use of a Model-View-Controller pattern. But MVC-oriented web applications have glaring limitations. The frameworks subvert the Web model (for example, Universal Resource Locators [URLs] are no longer valid) and convoluted ‘switch’ statements are often used to route client requests to back end transactions.  Additionally, the browser container hailed in the late nineties as the ultimate application host has enslaved application development and balkanized the runtime landscape. A disconnect between client and server capabilities existing in the frameworks, supported languages, and domain models. Client tier development has remained on a starvation diet for the last eleven years, and the backlash against the gaunt, thin clients is on the rise.

 

While presentation frameworks have experimented with event models and added buzzwords to their ‘features list’ (AJAX, Web 2.0, Service Oriented Architecture [SOA], and Rich Internet Applications [RIA]), a Redpill is needed to break out of the MVC Matrix and enable creation of ‘fit clients’. Vendors such as Adobe, Appcelerator, and Lazlo Systems  enforce loose coupling between client pages and server-side application logic by injecting a service layer. A message-oriented interaction instead of a page-oriented interaction will enable developers to experience a new perspective on application interactivity, decouple client-side technologies from server-side technologies, and break down traditional application silo boundaries.

What is in a name?

Blogger: Richard Monson-Haefel

Like it or not, there’s something to this meme called “Web 2.0”. There is a pattern, a design, an architecture that certain web application have in common that set them apart from the rest of the web. In my last blog entry I pointed out that the very heart of “Web 2.0” is “an Architecture of Participation based on the World Wide Web”.

This blog is important to our service in that it’s a sounding ground for ideas and as such it draws as much criticism and praise from outside the company as within. One of the major criticisms that I heard (through private e-mail) was complaints about the name “Web 2.0”. Seems that that label really bothers some people – I’m not sure why. But the point isn’t the name, it’s the paradigm, or more precisely the question of weather there is a new paradigm.

I was initially very critical of the meme “Web 2.0”. In fact, I made fun of it myself when I first heard it. However, my research of the World Wide Web required that I investigate the meme and form an opinion based on analysis rather than gut reaction. After more than three weeks I’ve come to the conclusion – having read a great deal of positive, negative, and neutral opinions and theorizing on the subject – that call it what you will, a new paradigm built on “an Architecture of Participation based on the World Wide Web” - has been discovered. Notice I say discovered, rather than created. That is the nature of patterns and paradigms: we tend to discover them. Paradigms are rarely “created” out the blue, but evolve from new thinking.

So let’s say that Web 2.0 - or the Participatory Web or the Interactive Web or whatever – is a newly discovered way of architecting web applications. Is it so horrible that people want to identify, categorize and name it? Who cares what we call it: it exists and “Web 2.0” is as good as any other name.

So does the fact that a new web application paradigm has been discovered mean that the old way of doing the web goes away? No. In fact, paradigms of the web coexist and are employed in parallel of the Web. When people started floating in boats did we give up walking? When wheels were invented giving rise to carts, chariots, and bicycles did we stop walking or floating in boats? No. New paradigms in transportation are discovered throughout history (walking, floating, riding, driving, flying) but old paradigms continue to exist. This is also true of the Web.

If you look at the World Wide Web today there appears to be at least three different paradigms which exist in parallel. Web 1.0 which is commonly associated with static web content. Web 1.5 which is commonly associated with dynamic generation of HTML, and Web 2.0 which is based on an architecture of participation. In a report I wrote that is due out soon I call these the Static, Dynamic and Interactive Webs – but again these are only labels for patterns that exist in parallel. The point is if you don’t like the name Web 2.0, than get over it. You probably didn’t like the term Ajax either, but you survived.  Besides, the term has already hit mainstream so you might as well use it.

What’s important is that a new way of doing things; a new paradigm for the web has been identified and we should understand it. As Donna Bogatin points out frequently, there isn’t a clear path to riches with Web 2.0. It may be a long time before anyone makes good money with the concept, but that doesn’t lesson its importance. It’s a game changer just as open source software, another Architecture of Participation, is a game changer. No one knew how to make money with open source either – they still don’t have a very good model in my mind – but no one doubts its importance. Web 2.0 is going to change things, so get over the name and try to understand its essence.