Dion Hinchcliffe's Blog - Musings and Ruminations on Building Great Systems

The need for businesses to open up their silos of information and internal capabilities to their internal customers has become an increasingly pressing issue as organizations strive to increase operational efficiencies and innovate more effectively with existing resources in the business and technical climate of early 2008. And in the last couple of years, as exposing uniquely powerful sets of data to online business partners has moved into the mainstream in the form of open Web APIs, opening up our IT systems across the Internet has become a competitive imperative as well. Unfortunately, despite two decades of experiments in heavyweight software engineering (the alphabet soup of EAI, SOA, ESB) for solving these types integration problems, we've seen relatively marginal improvements for most implementors despite heavy investments by businesses large and small. In short, integration between the systems running our business still isn't happening at the levels we need. However in the last several years, promising developments from the Web are pointing a way to a better model that seems to overcome many of the adoption and effectiveness issues of traditional SOA and is gaining wider adoption yearly (see sidebar below, right).

Most of us would agree that we still can't easily get access to the data and the systems we need to in order to get our daily work done. Workers still spend a great deal of time copying and pasting data between their various applications, data is batched and then exported and imported between IT systems around the world millions of times per day, and information just isn't getting to the places that we want it to without unacceptable amounts of manual labor. Even though Service-Oriented Architecture (SOA) initiatives around the world have the right goals, most efforts have fallen profoundly short of our desired levels of integration and improved business agility.

However, the news isn't all bad, the fascinating story is that there is a place today where the deep integration of our systems and information on a large scale has largely been solved and is a foregone conclusion in most cases. And that place is at the leading-edge of the World-Wide Web, sometimes referred to as Web 2.0. This success story has taken a while however and it's also managed to fly under the radar of most enterprise architects and IT vendors in the process. The left-hand turn that Web services took early on in the Internet story (circa 1999-2000) with SOAP, WSDL, UDDI, and WS-I Basic Profile turned out to be definitely not the right answer for the vast majority of integration scenarios (we'll see why below), despite the continued prevalence of these approaches today in most enterprises.

In contrast, the vast living laboratory of the Web has provided a singularly different answer, than has a fundamentally different focus though it remains a close cousin to traditional SOA. This much more Web-oriented approach is something that many have called Web-Oriented Architecture (WOA) and is based on the immense tensile strength of the World Wide Web itself and its underlying architectural fundamentals. And it's based on the basic concepts and rich outcomes that have made the Web far and away the largest open network on the planet as well as the largest SOA presently in existence. At the leading end of this is the Web mashups story with enterprise mashups being one of the major improvements to the IT landscape that WOA is heralding.

So to loosely paraphrase a famous line from history, I come to praise SOA, not to bury it. In the process I hope to explain WOA as simply as I can. This is still important because WOA just isn't standard fare yet for discussion in many IT circles while it's something that folks that build online services out on the globally scalable consumer Web increasingly take for granted. There are few vendors (though growing) that have lined up behind this pragmatic, effective, efficient, and highly popular approach, further limiting the body of formal knowledge and support available to practitioners who want to transplant this profoundly useful and simple way of connecting our systems together.

You may have noticed I've left "easy" out of my lists of adjectives describing WOA. And that's because I don't believe it's easy to set aside the last decade of evolving mindsets, habits, investments, tools, and skill sets for a better alternative, no matter how compelling or promising. And WOA is more than just a way of building Web services, it's also an ecosystem mindset and as such can at times be less accessible to non-system thinkers, particularly if said alternative is not well documented in the industry. And though significant headway has been made recently, particularly with an excellent spate of books such as Sum Ruby's superb RESTful Web Services, the grassroots, emergent nature of WOA has not lent itself well to extensive formal documentation. Despite the improvements in the available literature, I still find that a succinct, direct, and complete explanation of WOA is lacking and here's my attempt to boil it down to the essential principles. I then contrast it with traditional SOA so that the differences and similarities are clearly highlighted. Here's what I've come up with:

What is WOA? The Basic Tenets

• Information in a WOA is represented in the form of resources on the network and are accessed and manipulated via the protocol specified in the URI, typically HTTP.
• Every resource on the network can located via a globally unique address known as a Universal Resource Identifier or URI complying with RFC 3986.
• Resources are manipulated by HTTP verbs (GET, PUT, POST, DELETE) using a technique known as Representational State Transfer or REST.
• Manipulation of network resources is performed solely by components on the network (essentially browsers and other Web servers).
• Access to resources must be layered and not require more than local knowledge of the network.
• It is the responsibility of the components to understand the representations and valid state transitions of the resources they manipulate.
• The service contract of WOA resources is implicit; it's the representation that is received.
• WOA resources contain embedded URIs that build a larger network of granular representative state (i.e. order resources contain URLs to inventory resources).
• WOA embodies Thomas Erl's essential Principles of SOA, though in often unexpected ways (such as having a contract, albeit implicit).

WOA Implementation Guidelines

The basic tenets above paints a picture of a galaxy of nearly infinite granular information resources integrated into a deeply interconnected set of dynamic connections that can be processed individually for a given task, in part (for integrated applications), or as a whole (such as enabling a comprehensive directory or search engine of all data and metadata.) In other words, the Web model provides a single, open, and unified information architecture that is consistent, easily consumed, extremely scalable, securable, very reusable, resilient, and highly federated. The Web itself is the single largest example of this and increasingly, enterprises are adapting their existing IT systems and legacy silos to this model, discovering the advantages of this ecosystem model for information resources and enterprise architecture.

But the basic tenets previous list are at the architectural level. How does an SOA practitioner ensure they are implementing a WOA model as they build WOA Web services and resource-enable existing services and IT systems. Here are the key guidelines to be aware of:

• Every WOA resource should have the same unambiguously and globally unique URI on the local (SOA) network as well as the World Wide Web.
• In general, URIs should be descriptive of the resource to the extent possible. For example, http://domain.com/blogs/feeds/sruby.atom is strongly preferrable to http://domain.com/resources/12345678.
• The type of resource representation (XHTML, XML, MP3, AVI, etc.) should be encoded in the URI itself. Using the .xml extension at the end of a URI is a common convention, for example.
• A set of resources of a particular type should expose all known URIs in some manner (a WOA resource that provides granular, paged navigation for example) to enable linking, discovery, enumeration, browsing, and consumption in general.
• Query string parameters are generally not considered part of the URI possibly excepting resources that represent algorithmic or functional outputs. Move query strings to the URI whenever possible.
• Encourage URI self-reliance by limiting information that is communicated via HTTP headers when it can be moved to the URI. The Web cannot propagate header information, but links can.
• Resources should link to related resources via embedded URIs instead of making local copies. This is the core of the hypermedia concept that makes the Web and WOA provide its unique capabilities.
• WOA resources must careful to preserve idempotency for state transition consistency.

The major differences between traditional SOA and WOA

• SOAs tend to have a small and well-defined set of endpoints through which many types of data and data instances can pass. WOAs tend to have a very large and open-ended number of endpoints; one for each individual resource. Not an endpoint for each type of resource, but a URI-identified endpoint for each and every resource instance.
• Traditional SOA builds a messaging layer above HTTP using SOAP and providing unique and sometimes prohibitive constraints to the Web developer, while WOA finds HTTP and related transfer mechanisms to be the ideal layer of abstraction for most applications.
• SOA was designed from the top-down by vendors to be tool friendly, while WOA was emerged form the bottom up from the Web naturally and has the best support in simple procedural code and an XML parser.
• SOA uses WS-Security and other sophisticated standards for security, while WOA tends to just use HTTPS.
• SOA must contend with the vagaries of XML Schemas for service contracts, while WOA largely ignores the issue and lets Web services naturally represent whatever formats are desired.
• Traditional SOA is fairly cumbersome to consume in the browser and in mashups while WOA is extremely easy to consume just about anywhere.

I should close by emphasizing that I enjoy and use traditional SOA technologies like SOAP, WSDL, and XSD frequently. But as more and more of the consumer Web moves to a more Web-oriented model, the evidence continues to mount that approaches based on WOA are easier to implement, scale better, and result in much greater uptake and usage scenarios. Traditional SOA is facing a crises of identity at this point, particularly given fairly lackluster results for most, and WOA may just be the prescription we need to make SOA deliver the robust outcomes that we were formerly expecting of it. Especially read the article I wrote last year (below in the reading section on eleven new ideas for SOA architects) to show the promise of and a new vision for user-controlled SOA and other aspects that WOA enables and that traditional SOA tends to constrain.

Other vital reading on the convergence and evolution of SOA, WOA, and Web 2.0:

• WOA versus ROA by Sam Ruby
• The story of Web 2.0 and SOA continues
• Eleven Emerging Ideas for SOA Architects in 2007
• SOA Versus Web 2.0? by John Hagel

Note: I reserve the next few days to clean up and revise this article. In the meantime, please share your SOA vs. WOA stories and opinions below.

Update: ZDNet's Joe McKendrick provides some coverage of these ideas in a new post.