In the enterprise environment where agility and reusability are very important assets, SOA has been the most prevalent paradigm for last several years. But contrary to the expectation, the skepticism about ROI and the complexity of implementation have prevented the proliferation of SOA. Finally, people have chosen “Web” services not Web “Services”.

Web-Oriented Architecture

In 2005, Nick Gall from Gartner coined the term WOA (Web-Oriented Architecture) to describe Web-based SOA.

WOA = SOA + WWW + REST

However without any official definition or clear consensus about the meaning, there were lots of discussion about the term. Dion Hichcliffe and other experts tried to define the meaning of WOA, but there was a slight difference between their opinions. After all, on November 11, Gartner published an official note about WOA.

WOA is an architectural substyle of SOA that integrates systems and users via a web of globally linked hypermedia based on the architecture of the Web. This architecture emphasizes generality of interfaces (UIs and APIs) to achieve global network effects through five fundamental generic interface constraints:

1. Identification of resources
2. Manipulation of resources through representations
3. Self-descriptive messages
4. Hypermedia as the engine of application state
5. Application neutrality

Like the author said, the first four of the five interface constraints of WOA are the same as REST’s uniform interface constraints. However the last one Application neutrality has been newly added.

Application Neutraility

One of the most important goals of SOA is to maximize reusability, which means achieving better scalability. Scalable systems can be built using middle out architecture.

Middle out architecture is neither top down nor bottom up method. It’s the way to design an abstract interface at the center first and then expand it to the top and bottom. The interface called IFaP is an abstract combination of Identifier standard, Format standard, and Protocol standard.

A representative example of middle out architecture is the Internet. The interface of the Internet consists of IP address, IP packet, and IP protocol, and each respectively plays the role of Identifier, Format, and Protocol. Based on the interface, the Internet has been expanded to the diverse applications including Web and VoIP, and the several new platforms like Linux, successfully providing stable services.

Application neutrality of WOA is also about IFaP. A fundamental characteristic of the Web is serendipitous reuse, highlighted by Tim Berners-Lee and Roy T. Fielding. Serendipitous reuse can be achieved by general and application neutral interfaces. In other words, the more application neutral a interface is, the more reusable it is.

• “Unexpected reuse is the value of the Web” (Tim Berners-Lee)
• “Engineer for serendipity” (Roy T. Fielding)

However, WS-* standards more focus on implementation neutrality than application neutrality, says the author. Implementation neutrality of WS-* standards can help support various middleware technologies, but application neutrality plays more significant role in creating powerful network effects. So, WOA strongly emphasizes application neutrality.

Application neutrality should be the principal goal of an interface, and implementation neutrality should be a secondary goal.

How Neutral?

At Jazoon’07, Roy T. Fielding said SOA is null architectural style which has no constraints at all. But WOA has at least the 4 different uniform interface constraints of REST. The issue is the last 5th constraint, application neutrality.

The author insists application neutrality is an implicit constrtaint in REST, and every interface element should be defined as generic as possible.

Don’t just build on generic interfaces; build up generic interfaces that are only slightly less generic than those built on.

However, how generic does it need to be? What is the basis for determining if an interface is generic? If going from neutral to specific is a continuum, how granular will it be?

For engineers to understand and adopt WOA correctly, and to build practical systems based on it, the questions above may need to be answered clearly.

However, I have a few points I’d like to make.

1. Resource states and application states need to be explained separately.

   GET and HEAD are special cases since they don’t cause state transitions.

   As the above quote says, GET and HEAD don’t change any resource states. But they do cause application state transition. Think about Web browsers. When you click a link on the page, the Web browser will GET a representation of the resource pointed by the URI and move from one state to another. That’s exactly how you can see this page on your Web browser.

2. Everything you need to know is media type.

   <next/> tag in the article is primarily about hypermedia. The authors said the XML dialect used by Starbucks can embed information about another resource. However, IMHO, the only information that need to be embedded in that dialect is the identifier of the resource, such as URL.

   Here is where “Hypertext As The Engine Of Application State” comes into play. The next state has to be described by only a representation of the resource. A single resource can have multiple representations in different media types, each media type defines its own processing model, and every resource representation can be described by themselves (i.e., self-describing resource representations).

   So I don’t know why we need another namespace or a sort of standard for abstract state transitions. State transition is one of the basic notions of REST. Even if we have that namespace (like http://example.org/state-machine), we still need to define semantics of each type of transition in another namespace (like http://starbucks.example.org/payment). Furthermore, as long as the representation is self-described, we don’t need to set the rel attribute to the type of the representation in advance, because it can be derived by negotiation with the server. So, like the below, we can define a tag for a specific type of transition and its semantics can be defined by the tag itself. Then, we can re-use or standardize the namespace which defines that tag.

   <order xmlns="http://starbucks.example.org/">
     <drink>latte</drink>
     <additions>shot</additions>
     <cost>4.00</cost>
     <payment>https://starbucks.example.com/payment/order/1234</payment>
   </order>

3. The human Web is also RESTful.

   The consumer application – the Web browser – simply renders the HTML, and the state machine (that’s you!) follows links using GET and POST. In Web-based integration the same occurs, except the services and their consumers not only have to agree on the interaction protocols, but also on the format and semantics of the representations.

   I guess the above quote is in sort of contradiction to the following.

   In the human Web, consumers and services use HTML as a representation format. HTML has its own particular semantics, which are understood and adopted by all browsers.

   IMHO, in the human Web, the same occurs without any exceptions.

4. Some other comments…

   • I also think the use of PUT for partial updates is not a good idea. POST or PATCH seems a better option.
   • I wonder if using OPTIONS or Expect/Continue is always of benefit.
   • “URIs represent the transitions within a state machine.” is too simple and not accurate.
   • I think even if the resource is editable, there should be only one address for that resource.
   • We don’t need to use Microformats in XML. What about RDF?
   • I totally agree with the authors’ opinion about URI templates.
   • We have to understand the importance of evolution and partial understanding on the Web.

I guess the authors know very well everything that I mentioned above, but some newbies like me could be misled in some way. Anyway, this article is excellent and worth taking time to read.