WOA is neither SOA nor REST

I admit that I am only catching up on the whole Web Oriented Architecture (WOA, See What Is WOA? It's The Future of Service-Oriented Architecture (SOA) ) buzz. But I don’t think it is true that Web-Oriented Architecture" to represent the concept of "SOA plus REST", because based on my reading of the definition, it is neither:

• A WOA is not a SOA because it is not description oriented. Without a description language such as WSDL, publishing and subscribing to services becomes problematic.
• A WOA is not REST because it does address “state transfer” part of REST. While I can see WOA works well in many simple cases of web application design, I believe it needs to be complement with, yes, traditional SOA, and semantic web technologies to solve complex problems, for one simple reason: not all service interactions can be modeled as CRUD.

Let’s take a very simple example: travel reservation. Let’s assume that the travel agent has implemented a WOA style service. So a client (any client on the web) can create a Reservation (Resource identified by a URI) through a simple HTTP PUT. Let’s say the Reservation is “on hold” initially. And a representation (let’s assume XML) of the Reservation is return to the client:

<reservation xmlns="…">
<flight>UA989</flight>
<date>2009-04-01Z</date>
<status>Held</status>
</reservation>

Now, maybe a day later, the client wants to purchase this reservation. What should it (since the client is not a human being in our case) do? The logical options are

1. Do an HTTP POST with a new Reservation.

<reservation xmlns="…">
<flight>UA989</flight>
<date>2009-04-01Z</date>
<status>Purchased</status>
</reservation>

But the problem is how we can ensure that the user does not change other parts of the reservation like Flight. If the answer is the system simply ignores the Flight information on a POST, how can we make that constraint known to any client on the web?

2. Do a partial update, in which case you probably need to define a whole protocol like WSRT

3. Make the Status a separate Resource. So, you would do

POST /Reservation/20090401UA989_1234/Status HTTP/1.1
… …
Purchased

The problem here is how does the client extract information about the link between resources /Reservation/20090401UA989_1234 and /Reservation/20090401UA989_1234/Status from the representation of the Reservation as, per Fielding,

A REST API should be entered with no prior knowledge beyond the initial URI
(bookmark) and set of standardized media types that are appropriate for the
intended audience (i.e., expected to be understood by any client that might use
the API). From that point on, all application state transitions must be driven
by client selection of server-provided choices that are present in the received
representations or implied by the user’s manipulation of those representations

Of course we can bring RDF in to solve this, but it is not clear how semantic web fits in the WOA stack.

Web Service Support in JBossESB

I made an assertion that JBossESB 4.4 did not come with an out-of-the-box SOAP listener. As a result, a user has two options to get a SOAP over HTTP message onto the ESB:

1. Process the message on the ESB through an HTTP listener. The draw back is that is that the payload of the ESB message will be the SOAP envelope instead of domain objects. And the listener will not be able to support WS-* since it does not process SOAP headers.


2. Process the SOAP message with a web service hosted in JBossWS. This “ESB-aware” web service then pushes an ESB message to the ESB message through the service invoker interface, as shown in diagram below. The advantage of this approach is that QoS policies, including WS-*, can be enforced by the web service. The disadvantage is that the user will not take advantage of the ESB’s support for transport protocol bindings.

I was immediately challenged because some marketing material had said that JBossWS is now part of the ESB. First, that is not what the JBoss download page says:

The jbossesb-server binary distribution is a pre-configured profile based on the JBoss Microkernel architecture. The ESB Server comes pre-installed with JBoss messaging, JBoss Webservices, all of the base ESB capabilities and is the best choice for those who want to get started quickly.

The jbossesb binary distribution is a standalone distribution of JBoss ESB. The distribution comes with installation scripts allowing it to be installed into a full JEE
application server, if required.

Aside from the marketing, however, I think what got people confused is the fact that JBossWS hosted web service can be exposed as an ESB endpoint through the SOAPProcessor action. (Oh, the web service can even be deployed with the ESB achieve…..So great! :)

But what gets exposed by SOAPProcessor is really an ESB endpoint, not a web service endpoint, as pointed by JBossESB Programmer’s Guide:

The SOAPProcessor action allows you to expose JBossWS 2.x and higher Webservice Endpoints through endpoints (listeners) running on the ESB (“SOAP onto the bus”). This allows you to use JBossESB to expose Webservice Endpoints (wrapper Webservices) for services that don't expose a Webservice Interface. JBossWS Webservice Endpoints exposed via this JBossESB action are “ESB Message Aware” and can be used to invoke Webservice Endpoints over any transport channel supported by the ESB.

To be precise, in this approach, JBossWS acts as a service container for some POJO programmed to the conventions of JAX-WS. Because the web service endpoint is not exposed by the ESB through SOAPProcessor action, you will still need to use one of the two alternatives outlined above, as suggested in the diagram below.