Web Services Addressing and JAX-RPC

The idea behind addressing is to allow non-HTTP transports as well as HTTP transports, and even a chain of transports before a message finally gets to its destination. This would mean that a SOAP request can be routed via different platforms (JMS, HTTP, SMTP to name a few) and still make it to its destination. This goes hand in hand with asynchronous SOAP… Another major idea in WS-A is to allow acknowledgements, replies and faults to be returned to other addresses different from the original sender of a SOAP request.

A major consequence is that once again, the JAX-RPC processing model has to be stretched to accomodate this new standard. To see why, let’s consider what happens in a typical JAX-RPC service endpoint:

An incoming request message is received via HTTP.

One or more handlers (intermediaries) are allowed to pre-process the message (mainly its headers).

The service implementation gets the message to do the real (business) part of the job and generates a reponse (if applicable).

One or more handlers get to post-process the response.

The HTTP conversation is terminated by sending an acknowledgement (with or without a response message).

This is almost inherently a synchronous request/reply paradigm, and things like returning a reply to a different address become very cumbersome: this has to be done in a handler that shortcuts the reponse chain and sends the SOAP message somewhere else instead…

This entry was posted
on Thursday, October 13th, 2005 at 11:45 am and is filed under Solutions, Uncategorized.
You can follow any responses to this entry through the RSS 2.0 feed.
Both comments and pings are currently closed.