Integration of Web Service Stacks in an ESB

Slides from the BOF session at JavaOne

View more Microsoft Word documents from bfmj4fj.

Enhancing the Role of a Large U.S. Federal Agency as an Intermediary in the Federal Supply Chain via a Service Registry and a JBI-Based ESB

We did a technical session at JavaOne

http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-4389&yr=2009&track=soa

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.

Service Composition, Service Mediation, and the role of WSDL

It does not seem like we’ll get a break from the whole SCA vs. JBI controversy any time soon. Until the industry agree on what proper relationship between them should be, I don’t think there is any real hope for JBI 2.0, which is really sad for those of us advocating for a standard based ESB.

So, how should SCA and JBI work together? The answer always depends on who you ask. From the JBI perspective, JBI provides a platform for service mediation, while SCA can be used for composing these services for a particular business purpose (a composite application). From the SCA perspective, SCA is for making composite applications and JBI can be used as a specific SCA binding.

I have been thinking about the subtle difference between service composition and service mediation. Service composition, as SCA correctly pointed out, is about grouping platform independent services together to serve a business purpose. The key point is that the platform specific concerns are left to specific bindings, which is probably close to the soaML work that is going on at OMG. In many ways, composite application can thought as a programming model – when you are designing a composite application on a SCA platform, you need to know SCA! (On the other hand, an application developer designing a service should not be aware of an ESB, whether it is JBI based or not)

Service mediation is about providing a common platform at runtime for service interactions, which implies a few things, the most important being the need for a common way to describe services. For that, I think we have pretty much settled on WSDL and WS-Policy. I think the JBI approach, i.e., ESB endpoints described using WSDL and an NMR based the WSDL 2.0 message exchange patterns, provides a better mediation platform.

The role WSDL plays in service mediation is also recognized by SCA – the use of Mediation Modules shows that. But if WSDL is good enough for bridging SCA with the external world, why aren’t they good enough to describe the internal ESB endpoints that make up a composite application?