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

Jacques,
I can appreciate the challenges you face, but I still don't think it will 
help to mix together various WS-* specs with the SOAP over JMS spec (or 
SOAP/HTTP for that matter).    It is up to a vendor that is implementing 
various specs to provide something that is useful for a particular user 
problem...  in other words, a "solution" rather than just a collection of 
spec implementations.

> So, at the end of the day, for asynchronous Request Reply,  it is VERY 
difficult in the real world to stick to the JAX-WS API, which is the 
objective.
I think this might have more to do with the implementation (runtime) that 
you're trying to use more than it is the specification of the individual 
pieces that make up that implementation.     Vendors should try to provide 
a solution that solves a particular customer problem, rather than simply 
implementing a spec.    I would be interested in finding out what 
particular problems you've encountered that prevent you from sticking to 
the JAX-WS API.   Perhaps those need to be addressed by the JAX-WS 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 09:19 AM
Subject:
NEW ISSUE: is WS-Addressing irrelevant to "SOAP over JMS"?




De : Phil Adams [mailto:phil_adams@us.ibm.com] 
Envoyé : mardi 29 juillet 2008 15:44

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. 
 _______________________
I agree, we are indeed using JAX-WS and I am fully aware that the WG "SOAP 
over JMS" has a very focused mission. 
But I am still reluctant to admit that the sync/async can be dealt with 
entirely in the upper levels, and that the binding people (you) should not 
care. But I am willing to be educated !
 This is part of the  general  "hair-splitting" problem in the WS-* 
universe : half of the specs in W3C, another half in OASIS, all of this to 
be composed, but the user has to guess the recipe for composition, since 
ws-i.org seems to be somehow lost in the mist for a while .
My current problem is that  when we pile up: JAX-WS + customer_favorite_WS 
toolkit (CXF these days) + toolkit2jms binding (currently non existing) + 
customer_favorite_MOM , this just does not work because  (in a nutshell) 
JAX-WS is WSA friendly but  the MOM  ignores WSA.
So, at the end of the day, for asynchronous Request Reply,  it is VERY 
difficult in the real world to stick to the JAX-WS API, which is the 
objective.
That 's why I do believe that you (the JMS WG) are in the best position to 
align the whole stack and tell users (and provide products)  how to handle 
the most obvious MEPs, so that we can program them in a vendor independent 
way, which is the whole purpose of W3C and WS in general.
Sorry if, due to the fact that I am not really an expert, I somehow 
interfere with the global WG flow. At least, I believe a naive user in the 
loop is not that bad (I have been on the other side of the fence in a 
previous life). 
Bye
Jacques