Web-oriented architecture and the rise of pragmatic SOA

Web-oriented architecture (WOA), a descriptive term for a subset of service- oriented architecture (SOA), has recently arisen as the next buzz-phrase to help further confuse the IT architect.

WOA is simply a way of implementing SOA by creating services that are RESTful resources, allowing any service or data to be accessed with a URI. (REST, by the way, stands for representational state transfer. And URI is short for uniform resource identifier.)

For many scenarios, this method dramatically simplifies things over the traditional WS-* approach. WOA resources are stateless and self-descriptive. Additionally, building SOA across intra-enterprise and in-the-cloud services becomes much easier with WOA.

As defined by Gartner's Nick Gall (thanks to Rob Eamon for the pointer):
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

To be clear, the WOA approach is not ideal for every scenario. As with any architectural style, there are trade-offs. Any application that requires a real-time, event-based action or response, for example, can't be easily built in the WOA way (at least without crippling the system with constant polling). For the enterprise architecture with any level of complexity, no one approach will fit all needs.

Add in the inevitable enterprise mix of legacy applications, existing investments in SOAP-style SOA, and point-to-point integration infrastructure, and it becomes clear that the true pure-play WOA will be all but nonexistent.

So, what about WOA governance? Does the emergence of the distributed, resource-oriented WOA mean that governance will be fundamentally different? Does it mean that a previously centralized, top-down SOA governance will give way to a bottom-up, federated approach? The answer is both yes and no.

Top-down centralized SOA governance has been a failure to date. The inherent complexity of trying to manage sprawling enterprise architecture with the enterprise architect's iron fist, combined with overly complex tools and protocols such as UDDI have all contributed to the shockingly high failure rates of SOA.

Any SOA governance strategy needs to manage ALL of an enterprise's IT artifacts--not just WS services, or WOA resources. Governance practices need to emphasize best practices, artifact discovery, and collaboration rather than top-down policy enforcement. Tools need to be pragmatic and useful to developers from day one.

In the end, WOA is just one more way to build service-oriented applications and will need to co-exist as a part of a larger enterprise SOA. SOA governance practices and tools will necessarily need to evolve to accommodate WOA and adapt to reflect the benefits that REST and WOA bring.

The pragmatic developer or architect recognizes that WOA is a way to solve a particular problem. It's not the total solution.