This article describes a new set of basic usage patterns that are intended to capture the current state-of-the-art in designing interactions with Web services in mature, robust Web-Oriented Architectures (WOA). For those just tracking it, I've covered the concept of Web-Oriented Architecture in the past, but it essentially describes the subset of service-oriented architecture (SOA) that is most useful in highly federated systems. And by this we specifically mean distributed systems made up of very diverse and unlike types of clients and servers. Of course, this is the natural, everyday environment of the Web itself, as well as many large enterprises.
I recently summarized the core subset of these interaction patterns, especially for WOA clients and Web services, in the summer 2006 edition of Microsoft's The Architecture Journal, Issue #8, in an article titled Patterns for High-Integrity Data Consumption and Composition. This article contains the results of both our most current practical experience as well as our best present analysis. We believe it is the most ideal model for making heterogeneous service-oriented architectures easy to design, develop, maintain, and sustain.
In general, WOA/Client is based on what seems to be working "in the wild" as best practices for Web-scale systems. This usually means 1) avoiding automatically generated stubs, 2) reducing serial abstractions between the service and the client, 3) clearly understanding what's happening over the network on your behalf, and 4) periodically rechecking basic assumptions programatically. In most cases we're finding that WOA works best using REST or or POX over HTTP, though REST is clearly more desireable. Do keep in mind that REST can require more effort and better engineering capability to implement, at least initially, though that should do nothing to discourage you from using it.
WOA/Client works with just about any service model. Check here for a list of the ones that it could work with, though you may have to write your own contract.
The identification and naming of yet another new usage model for Web services was not taken lightly. The world little needs additional complexity when it comes to new terms and models for building distributed software systems. Yet it's clear that the models that were identified early on in our industry are not the ones in general use today given a run-time environment (the Global SOA if you will) that contains so many important differences in their participants. Consumers and producers of services on the Web today are faced with anticipating the platforms, languages, toolkits, and skills of those on the other side of the conversation. From this, it seems clear that the best way to connect people and systems is via an approach which is designed explicitly to enable the widest variety of consumption scenarios and be as inclusive as possible. Therefore, this is not traditional heavyweight SOA where the local environment is controllable enough to make it successful, or at least, possible. Rather, this is how to connect two entities of any type together across the Web in scenarios that a) are supremely easy to implement, b) robustly embrace ongoing change and evolution during system operation, c) are easy to maintain over time and finally, d) can clearly self-identify when inevitable changes do occur and degrade gracefully.
In the discussion here, REST is the protocol most preferred since it's a natural extension of HTTP for the purposes of sharing self-describing information and state. HTTP is today one of the most heavily used and successful protocols for sharing information over networks and is the fundamental underpinning of most Web services. REST solely uses HTTP to function and is designed to leverage its best qualities. Unfortunately, that a canonical description of REST does not exist for the layperson is an almost tragic circumstance. In my opinion, this has significantly interferred with WOA's ability to be implemented and adopted effectively in a widespread manner, though I also believe that will soon resolve itself.
Yet, as much as I appreciate and recommend REST, I am not a Web service bigot, and the patterns described here can be applied readily to any type of service-oriented architecture protocol and even beyond. Those designing and developing distributed systems on the Web today simply must recognize that we will increasingly not be able to control the other side of the conversation (for example, making the "mustUnderstand" header in SOAP very unfortunate indeed.) Thus, if you want the most loosely-coupled, most resilient, most maintainable connection to your SOA or Web 2.0 ecosystem, WOA/Client is how to accomplish it.
The target for all of this however, is ultimately Web 2.0 software architectures and the evolving next generation of the Web and WOA. The best software these days are highly open and easy to connect to and incorporate into other systems. The ideal of turning applications into platforms seems to be happening much more on the Web and less in the enterprise and therefore becomes our primary reference model. In this way, we can look at the more successful examples of WOA, such as Amazon's Web Services Division, to CDDB, and all of the APIs and resulting mashups that are currently listed on John Musser's excellent Programmable Web. This means the Global SOA is here, even if the enterprise SOA is often not. Analyzing, replicating, and adapting what works on the Web can only help spur real-world adoption of SOA elsewhere, and the WOA/Client is an attempt to embody the most successful way to do it.
WOA/Client Tenets
WOA/Client is a simple articulation of the design patterns that appear to work best when designing interactions between systems that were never explicitly designed to work together from the outset:
- Inclusive: The concept of Web services must be expanded to include anything transported over HTTP, and a workable engineering approach must be applied to this realization.
- Agnostic and Consistent: Service interaction must be agnostic yet consistent across platform, technology, protocol, data format, contract description language, and programming language.
- Expect Constant Change: One must assume that changes to the service's contract, protocol, or endpoint location is not only normal and inevitable, but can happen suddenly and unexpectedly.
- Mashup-Oriented: Integrating data from many sources and then defusing it again reliably, securely, safely across federated services is now a central activity in modern software systems.
- Deeply Resilient: Failure tolerance must be extreme since failure modes, degraded operation, and incomplete outcomes are actually normal occurrences on the Web. Pessimistic assumptions about the quality of the run-time environment are mandatory and must be regularly rechecked programatically.
- Bare Data: Lack of postive control, developer maintenance, the run-time cost of transforming data across many representations, and the abstraction impedance between them becomes unmanageable in Web-scale systems the farther one gets from the wire.
- Extreme Loose Coupling: The tolerance continuum is surprisingly shallow once one gets out onto the Web, and software architectures should reflect that.
Seeing Is Believing: Try WOA/Client For Yourself
If you're curious at what a WOA/Client might look like exactly, you only need look at some early examples I developed last year to prove out these concepts. In the aforementioned article on contract-checking clients, I developed Java, C#, and Ruby clients that exhibits most of the principles described here. The SOAP service described in the article is still running on this site (refer to the article for the WSDL). You are welcome to examine the source code, run the clients yourself, and get a feel for how such clients are much more resilient to changes to the contract (by only concerning themselves with the portion of the contract they care about), see how running close to the wire is easy with simple services, and see straightforward and highly effective mechanisms for clients to identify when and how unsurvivable changes to their contracts occur.
Figure 1: The patterns of WOA/Client shown in context
Now, I do anticipate there are some shortcomings with this early and initial descripton of WOA/Client. This is inevitable and all such omissions are mine and the plan is to correct them over time. Thus, as such, this is as complete and robust a descripton of WOA/Client as could be made at this time. I currently believe WOA/Client successfully captures the best general approach for consistently and reliably consuming the universe of possible Web services -- both on the server-side but particularly within the browser -- to create the highest quality, richest distributed software that will stand the test of time. Certainly, there needs to be further exposition, examples, discussion, and evolution of these concepts as time goes by. But I believe WOA/Client is a credible first step towards identifying a more mature, sustained interaction model for service-oriented software with which we can trust our lives and businesses. I do hope you'll leave your thoughts and comments below.
Update: Aug. 8, 2006: Good commentary on WOA/Client by Sam Ruby as well as coverage on the The Server Side.
Update 2: Aug. 10, 2006: Nick Gall, who coined the term Web-Oriented Architecture, adds to this discussion on his blog.
Update 3: Aug. 15, 2006: Detailed exposition on the first WOA/Client pattern has been posted here. This is the full strength "enterprise WOA" version of the contract checking pattern. I will post a lighter REST version that should make WOA advocates much happier soon.
I plan on continuing to articulate the advantages and disadvantages of our current models for connecting systems. Look for further exposition of WOA/Client.