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.

XML and Modeling

Blogger: Kurt Cagle

Data modeling is a big thing at Burton Group - a significant amount of the airtime expended in the ether around the virtual water cooler is devoted to teasing out the way that models interact, the best language for expressing such models and what characteristics best define a good model. In a way this isn't surprising - many of the people within the organization are former application or systems architects, and as such have a common belief that nonetheless is one that application developers don't necessarily share: before you write a single line of code, you should have a reasonably deep understanding of what particular piece of the real world you are attempting to model in that code.

Modeling, for the record, is hard. It is in a very real sense an attempt to predict the future by trying to determine, for a give set of problems, what the final application that solves those problems will look like. What makes this particularly difficult in many settings is the fact that these predictions often have to be made before real intangibles - what development environments and languages the systems will be built in, whether people with the adequate skills to program the pieces can be found, whether new technologies will emerge that will eclipse what is currently under develop and so forth - can even be made.

Impressions from GITA 2008

Physical infrastructure - roads, cities, bridges, sewer and power systems, that sort of thing - is not exactly at the top of the list of most people's ideas of exciting subjects, but they are nonetheless as necessary a part of daily life as food production and transport, oil production and laying of network cable. The GITA 2008 Conference - also known as Geospatial Infrastructure Solutions - has showcased that in very stark detail this year. Seattle once again showed off its reputation as one of the rainiest cities in the country, but the dark clouds and gloom outside served only to highlight the dark clouds and gloom on the inside.

XML - my bailiwick - is mostly about systems and information flow, and over the years I've come to develop a particular sense about systems theory in general, especially when it touches on IT. Yet the people here are system thinker's system thinkers, the ones that not only play SimCity but offered advice to its game designers, and frankly, they're very nervous right now.

Understanding the Benefits of XForms

Blogger: Kurt Cagle

XForms is something of an odd duck. Originally intended simply as a modularization of the HTML components so that they could better work in a more XML oriented environment, the XForms specification very quickly morphed into the foundation for a considerably more sophisticated application, albeit one that had a few ... idiosyncrasies.

For instance, unlike most other applications where the data model was bound into objects and object models, XForms defined its data models as blocks of XML, and the controls, rather than individually holding values that the application could set or retrieve via script, actually were bound to the data model - change a value in the model, and the control changed, change a control value, and the underlying model automatically reflected that change. Throw in bindings using XPath expressions, a purely declarative structure and working with models that could be loaded from the server or submitted to the server without forcing a reload of resources, and you could perhaps be forgiven for thinking that XForms was a language designed by committee (which, to be honest, is pretty much what happened).

W3C Standards are themselves a little odd, with the XML standards being particularly notable for this. In most cases, standards represent a consensus view about what the existing state of the industry looks like, only with the rough edges of controversy smoothed away in smoky, back-room deals (the truism of politics and sausage also applies to the creation of standards - one should never look too closely into how any of them are made). The W3C XML standards, however, involved a technology that itself had not existed until the W3C formally established it, though it did of course have the twenty five year old precedent of SGML to fall back on.

REST: Is it the Next Big Thing?

Blogger: Anne Thomas Manes

The APS team has been involved in a vigorous debate about REST for the last two months. Certain members of the team contend that WS-* has become bloated, unwieldy, and overly complex, and they fervently believe that we should not be recommending it any longer. Our resident RESTian also cites the fact that WS-* has no contraints, and therefore there's no way to ensure the properties and characteristics of applications built with it.

So if WS-* is a tragic mistake, does that mean REST is the next big thing?

Perhaps so. Vendors like IBM and Microsoft are starting to make major investments into technologies and frameworks that facilitate development using the REST architectural style. But for the moment, a steep learning curve and the dearth of available frameworks will stymie adoption. (For those looking to get started with REST, I recommend RESTlets.)

REST is not simply technology--it's an architectural style that's fundamentally different from they way most developers design systems today. It requires a noun-oriented approach to designing systems rather than one based on verbs. I know quite a few people that have been studying REST for years who still struggle with RESTful design practices. Understanding the basics of the style is easy. Truly groking it and being able to apply it to real-world situations is much harder.

Here are the basics:

• It is a resource-oriented style of design
• Every resource is addressable via a URL
• Every resource has a uniform interface
• State is exchanged via representations
• Messages containing representations are self-describing
• Interactions are stateless
• Representations reference related resources via hyperlinks

Note that REST is not the same as "plain old XML" (POX). POX refers to the format of a message payload, and it says nothing about architectural style. It just says that you don't wrap an XML message with an XML envelope (e.g., SOAP or Atom). More to the point, not all POX applications are RESTful, and not all RESTful applications are POX.

Likewise, REST is not the same as HTTP. HTTP is an application protocol. It's middleware, not an architectural style. It just so happens that HTTP is the only application protocol that fully supports the REST constraints. But a developer isn't forced to adhere to those constraints. In fact, not all HTTP applications are RESTful, and developers frequently use POST to tunnel method invocations (verb-oriented style). Also note that REST doesn't mandate HTTP, but it is the only standard protocol that implements REST constraints.

For those interesting in learning more about REST, I encourage you to sign up for Pete Lacey's half-day workshop, REST Easy, at Catalyst on Tuesday, June 26, 2007, in San Francisco.