Aside from allowing us to detect edit race conditions, the ETag header also allows us to conditionally request a resource. When we request an updated representation of our work item using the GET method, we can optionally pass in an If-Match-None header with the ETag value. This indicates to the resource to only send us back a new representation if the ETag value has changed. If the resource did not change, we receive a "204 No Content" response. This mechanism enables us to save valuable bandwidth and processing time.

Listing 4 shows the complete code to issue the conditional GET request.

Inspecting the Analyzer
Work items are not the only resource that benefit from the Atom representation. When we created our initial work item, we characterized the analyzer as a queue - or collection - of work items. Consequently, it makes sense to represent the status of the analyzer as an Atom feed. To retrieve the feed, we simply issue a GET request on the analyzer URI either from the browser or from a feed reader application. This means, we can at all times remain informed on the state of the analyzer.

Listing 5 shows what the analyzer's Atom feed would look like. The status of work items is either "processing" or "queued." Once a work item has completed, the submitter we'll be notified via the URI supplied in the work item. If the URI is a mailto: address, the analyzer will send out an email notification. Alternatively, if the URI is the location of another feed, the analyzer will publish a result Atom entry into it, potentially kicking off another processing stage.

Don't Assume. Discover
We've have seen how we used the contents of the work item to discover that it could be edited. But how did we discover the URI for the analyzer in the first place?

WOA advocates that all resources be discovered through a single, known entry point. This principle provides a clean separation of concerns between the agent and the network topology. Network applications often document their various entry points. However, once these are published, agents will hard-code them, and then it's almost impossible to change the network topology. Instead, agents should use a single known entry point into the network and discover other resources from it. This enables the application to remain in control of how network resources are distributed. For example, the application may provide alternate URIs based on availability or the location of the requesting agent.

How did we discover the analyzer? We requested an Atom feed of all top-level resources from our entry point. Then we used an XPath expression to find the link to the analyzer, just as we did earlier to find the edit link for our work item. If we want to save ourselves a round-trip, we can use a conditional GET request. If the feed hasn't changed, then our previous analyzer link will still be the same. Problem solved!

Summary
We have covered a lot of ground in this article. We defined WOA and REST in broad strokes. Then we put theory to practice and explored how WOA would be applied to an image processing application.

The examples illustrated the benefits of using established representations, such as Atom entries and feeds. The conventions defined by the Atom protocol gave us a well-defined processing methodology. If other processes within our enterprise are modeled using Atom, we will automatically have an intuitive understanding of them. This understanding scales outside of the walls of the enterprise to online web services as well.

We also saw how easy it is to work directly with HTTP, XML, and XPath using a WOA-friendly .NET library, such as MindTouch Dream. Using nothing more than raw HTTP request and response for documentation, we were able to translate resource interactions into running code that required just a few lines. In short, we were able to write our agent code close to the metal and it remained simple.

WOA is enterprise ready; because it's simple, scalable, and extensible, WOA leverages the benefits of HTTP, such as conditional GET and PUT requests. It also promotes the use of semantically rich representations. In our examples, we used Atom documents, but as stated in the introduction, we could have used (X)HTML or RDF documents instead. The specific document format is not as important as how broadly it has semantic consensus, because consensus is the investment to be leveraged. Just think for a moment about how much time you have spent in meetings to reach consensus with others. Now, take a step back, and ponder the value of a representation that has achieved consensus at a global scale.

As always, start small, but with determination, and you will quickly experience these benefits of WOA first hand.

References

• RFC 2616: Hypertext Transfer Protocol - HTTP/1.1
  
• Atom
• GeoRSS
• MindTouch Dream

• SOA and the Rise of WOA
• Web-Oriented Architecture (WOA) Gains Momentum