RE: [SOAP-JMS] minutes 2008-05-20

I was afraid that I would get myself in trouble :)

I think that the SOAP/JMS spec, as it currently exists, does a good job of 
specifying the set of properties that "should" or "must" be set on request 
and response messages and that description is a large part of the interop 
protocol that a conforming implementation must adhere to.       The spec 
does mention "JMS API" in a handful of places, but it doesn't explicitly 
talk about specific methods that should or must be called to conform to 
the spec.     If we're going to be that detailed in the spec, then we'll 
need to address the differences between JMS 1.0.2 and 1.1 (perhaps).

I'm sure that I've already made too much of this issue...   I'm perfectly 
happy with us describing the protocol in terms of the required and 
optional properties that are set on the request and response messages, and 
then testing for compliance by inspecting the messages that are created by 
the vendor runtime.

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




Philippe Le Hegaret <plh@w3.org> 
05/22/2008 03:04 PM

To
Phil Adams/Austin/IBM@IBMUS
cc
Amelia A Lewis <alewis@tibco.com>, SOAP/JMS <public-soap-jms@w3.org>
Subject
RE: [SOAP-JMS] minutes 2008-05-20






On Thu, 2008-05-22 at 13:38 -0500, Phil Adams wrote:
> Ok, I might be in the minority here, and that's fine if I am... but I
> disagree that we should be dictating the actual API calls that should
> be invoked in the JMS API by a conforming implementation.    If you
> want to talk about the fact that a conforming implementation should
> add string property "A" to the request message and that the values for
> "A" should be X/Y/Z/whatever, then that's fine, but I don't think it's
> correct to say that the conforming implementation MUST call the
> javax.jms.Message.setStringProperty("A",<value>) method within the JMS
> API layer to set the value.    I'm not taking this position because my
> implementation doesn't use the JMS API (in fact it does use it), but I
> know of other implementations that might want to "conform" but do not
> use the JMS API per se. 

Isn't the Working Group "responsible for producing a W3C Recommendation
for how SOAP should bind to a transport that supports the Java Message
Service (JMS) api" [1]? So, we don't have to consider implementations
that do not use the JMS API. After all, the relative interoperability of
JMS is defined by the JMS API. If we decide to enlarge that definition,
then I don't know what we're talking about anymore...

Philippe
> 
[1] http://www.w3.org/2007/08/soap-jms-charter.html