Web Ser­vices Ad­dress­ing and JAX-RPC

With the fi­nal­iza­tion and pub­li­ca­tion of Web Ser­vices Ad­dress­ing 1.0 - Core (WS-A) the world of web ser­vices has changed dras­ti­cal­ly (or will do so in the near fu­ture).

The idea be­hind ad­dress­ing is to al­low non-HTTP trans­ports as well as HTTP trans­ports, and even a chain of trans­ports be­fore a mes­sage fi­nal­ly gets to its des­ti­na­tion. This would mean that a SOAP re­quest can be rout­ed via dif­fer­ent plat­forms (JMS, HTTP, SMTP to name a few) and still make it to its des­ti­na­tion. This goes hand in hand with asyn­chro­nous SOAP... Another ma­jor idea in WS-A is to al­low ac­knowl­edge­ments, replies and faults to be re­turned to oth­er ad­dress­es dif­fer­ent from the orig­i­nal sender of a SOAP re­quest.

A ma­jor con­se­quence is that once again, the JAX-RPC pro­cess­ing mod­el has to be stretched to ac­co­mo­date this new stan­dard. To see why, let's con­sid­er what hap­pens in a typ­i­cal JAX-RPC ser­vice end­point:

1. An in­com­ing re­quest mes­sage is re­ceived via HTTP.
2. One or more han­dlers (in­ter­me­di­aries) are al­lowed to pre-process the mes­sage (main­ly its head­ers).
3. The ser­vice im­ple­men­ta­tion gets the mes­sage to do the real (busi­ness) part of the job and gen­er­ates a re­ponse (if ap­plic­a­ble).
4. One or more han­dlers get to post-process the re­sponse.
5. The HTTP con­ver­sa­tion is ter­mi­nat­ed by send­ing an ac­knowl­edge­ment (with or with­out a re­sponse mes­sage).

This is al­most in­her­ent­ly a syn­chro­nous re­quest/re­ply par­a­digm, and things like re­turn­ing a re­ply to a dif­fer­ent ad­dress be­come very cum­ber­some: this has to be done in a han­dler that short­cuts the re­ponse chain and sends the SOAP mes­sage some­where else in­stead...