Re: NEW ISSUE: is WS-Addressing irrelevant to "SOAP over JMS"?

All,
I am happy to discover that my mail made its way to your today's agenda, and that Eric took the time to better explain the context.

I will try below to precisely describe the use case we have in mind, which is a real world use case for "a big Telco customer", but is very generic in my opinion.

I do not really know whether the information needed belongs to the SOAPoverJMS spec itself, or is more appropriate for a use case document. I understand that if SOAP over http does not care about WSA, SOAP over JMS should not either. However, consider that some water has been flowing under the bridges in between the 2 specs (that what we say in french) and that more guidance is needed for the WS-* users.
So please favor usability over "correctness".

At the high level, the WSC-WSP exchange is intrinsically asynchronous, just because the WSP can answer in minutes or even hours.
So this is the classical Asynchronous Request Reply, the one you  implement with a sending Q and a receiving Q if you have  a MOM.
You probably realise that for most WS users, the distinction between WSDL and SOAP MEPs is a nightmare!
My understanding is there are 3 levels:

 *   WSDL asynchronous MEP: as seen from the programmer
 *   SOAP asynchronous MEP: as seen on the wire by e.g. SOAPscope
 *   Transport asynchronicity: JMS as opposed to http

This is not well understood by the WS community, nor well explained; many still believe that a synchronous SOAP|WSDL MEP becomes magically asynchronous because it is bound on an asynchronous JMS transport. To be honest, I am not really sure my 3-level mind model is correct :-(

So, to reiterate, we need an asynchronous WSDL MEP on top of an asynchronous SOAP MEP, bound on an asynchronous JMS transport. Synchronous RPC mapped on JMS is also interesting, but it is not the use case I am talking about.

We want to program the WSC in SOAP so that we can decide at the latest time, ideally at installation time, whether we will use an http or a JMS binding.

The WSC is able to provide a Reply-port, so a call back scheme is OK, we do not need a polling scheme.
The WSC is WS-Addressing capable. (This is recent BTW, you need axis2 or CXF or some recent commercial stack to actually have interoperability at the WSA level).
We need to minimize the differences for the user code regarding the 2 bindings. Thanks to Eric, I now realize that the http Reply-To port has to be specified explicitly, while the JMS reply-port can be left anonymous (if I understood correctly).

Again, as seen from the WSC, the asynchronous behavior (WSDL asynchronous MEP) can be simulated by the toolkit (as Axis is able to do) or can be on the wire. In our case, we want "asynchronous on the wire" (asynchronous SOAP MEP).

The problems we currently have is that we have to "pollute" our code with specifics of the underlying MOM; the user code is not only JMS-dependent, it is also MOM-dependent. Instead of a "nice" WSA reply-port, we end up with a MOM specific artefact. (If you recognise yourself, raise your hand :-)
Imagine the profile of the programming guy: very specific, rare and expensive! We would like any WS-fluent programmer to be able to program an asynchronous request-reply without knowing all the nitty-gritty details of the underlying plumbing.

Now you probably get an idea of the problem. How to solve it (i.e. in which document should all of this be clarified) is left as an exercise to the WG :-)
 We (poor WS-* users, subject to daily REST proponents bashing :-) need as much coordination and consistency between the WS-* vendors as possible, so that Async Request Reply becomes as easy to program as the synchronous RPC.
Perhaps this is a tall order and your WG is not able to fulfill it alone. But let's say I talk to W3C as a whole ...

Note: a suggestion would be; as an exercise, take the basic asynchronous uses cases of wstf.org and try to bind them on SOAP-JMS with minimal changes.

Hope this helps clarify our needs.

Jacques

--
Jacques Talbot - Teamlog 10 rue Lavoisier - 38330 Montbonnot
Tél: 04 76 61 37 12  Mél: jacques.talbot@teamlog.com
Tél. mobile 06 07 83 42 00