RE : RE : WS-Addressing

>Considering that JMS does not interoperate between vendors (no protocol), 
SOAPonJMS will not interoperate either.
That's correct, there is currently no interoperability between 
implementations of JMS (i.e. messaging products).   We specifically 
mention this in the spec (IIRC), and our goal with the spec is to define a 
way for web service runtimes from different vendors *that are using the 
same underlying messaging product* (e.g. WebSphere MQ) to exchange SOAP 
messages using JMS.        So, for example, a client which uses JAX-WS 
implemented on top of Apache Axis2 could invoke a web service that is 
available inside a WebSphere app server, assuming that the JAX-WS/Axis2 
and WebSphere platforms both comply with the SOAP/JMS spec AND both 
platforms are using the same underlying messaging product (i.e. JMS 
implementation). 

>So IMHO, the WG work should also care about facilitating / enabling 
portability of the user code, even if I understand that APIs (such as 
JAX-WS) are not directly a WG issue. 
Assuming that you use a programming model that is portable, such as 
JAX-WS, and the underlying technologies (e.g. SOAP/JMS) are also supported 
by the various runtime vendors, then your user code *should* be portable.  
  In fact, one of the goals of the SOAP/JMS spec is (at least indirectly) 
to allow user applications that use SOAP/JMS to be portable.    You can 
see this in the standard definition of the JMS URI syntax and in the WSDL 
elements that are defined in the SOAP/JMS spec.     I agree with you that 
the SOAP/JMS WG should care about user code portability and I think we 
already care about that and we have addressed it to the degree to which 
the SOAP/JMS binding contains features that are exposed to the user (i.e. 
JMS endpoint URI, WSDL elements, etc.).

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:
Phil Adams/Austin/IBM@IBMUS
Cc:
"public-soap-jms@w3.org" <public-soap-jms@w3.org>
Date:
08/20/2008 03:35 AM
Subject:
RE : RE : WS-Addressing



Jacques, 
You seem to be mixing programming model issues with issues of the 
underlying runtime. 
This is correct, but I am not sure I want to apologize since these are in 
fact intertwined in real life  :-)

What client programming model are you using in this situation?
JAX-WS
 
However, I don't think the shortcomings in the client programming model 
should be a reason to make the SOAP/JMS spec more than it is intended to 
be... that would confuse the issues more than it would clarify them, in my 
opinion.    I'm sure my SOAP/JMS WG colleagues will correct me if I'm 
wrong, but my opinion of the SOAP/JMS spec is that it is mostly intended 
to guide web service runtime vendors to enable them to provide a runtime 
that can interoperate with other runtimes when exchanging SOAP messages 
over JMS.       It does not, however, touch on the client programming 
model nor is it intended to. 
Considering that JMS does not interoperate between vendors (no protocol), 
SOAPonJMS will not interoperate either.
So IMHO, the WG work should also care about facilitating / enabling 
portability of the user code, even if I understand that APIs (such as 
JAX-WS) are not directly a WG issue. 
Whatever the WG recommend, even if non normative, can be used as an 
indication to the toolkit implementors and would help avoiding the 
differences we are seeing to-day as soon as you get out of the beaen track 
(SOAP RPC on http), which plague developer's life and hamper WS-* rise to 
the Gartner plateau of productivity.
Then, in a future release of the spec, or in another W3C spec,  what is 
non normative could become normative when best practices will emerge.
 
My 2 cents
Jacques