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

Jacques,
Have you considered using JAX-WS as the programming model for your 
consumer (client)?     JAX-WS provides an asynchronous API for invoking 
web services.  It offers both a callback and a polling model.   This is 
one of the advantages it has over JAX-RPC, which never included an async 
API.        Keep in mind that the SOAP over JMS spec does not specify a 
programming model for the end user application (web service consumer or 
provider).   It simply concerns itself with the interactions between web 
service runtimes.    So, the notion of a programming model (sync or async) 
is beyond the scope of the SOAP over JMS spec. 

Phil Adams 
WebSphere Development - Web Services
IBM Austin, TX
email: phil_adams@us.ibm.com
office: (512) 838-6702  (tie-line 678-6702)
mobile: (512) 750-6599




From:
"TALBOT Jacques (TJA)" <Jacques.TALBOT@teamlog.com>
To:
"public-soap-jms@w3.org" <public-soap-jms@w3.org>
Date:
07/29/2008 03:29 AM
Subject:
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