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

(more of a summary of where I think we're at)
 
Yup, It is critical that the robotic tester be pure JMS. 
 
To me this is where we start to illlustrates the real value of SOAP/JMS
and an important level of interoperability. 
 
The value being say, I am a Web Service Client that can consume Web
Services over SOAP/JMS using Vendor A. I want to replace Vendor A with
Vendor B. Vendor A and B both support JMS Provider X. I don't care that
Vendor A  is using some hidden APIs in X and that B uses pure APIs. I
should be able to talk to Vendor B by a URI change.
 
or
 
I am a Web Service Client that can consume Web Services over SOAP/JMS
using Vendor A. I want to replace Vendor A with Vendor B. Vendor A
supports JMS Provider X, Vendor B supports JMS Provider Y. I don't care
that Vendor A is using provider  X and that B is using provider Y . I
understand I have to change my JMS provider to one supported by
B(typically involves classpath and URI changes), but I should need to
rewrite  code .
 
etc, etc
 
I think that in both these cases above, Vendor A and B have important
claims to make about SOAP/JMS support.
 
The problem we need to confront is this - and that I have no answer for
- our charter might be interpreted as implying a stronger level of
interoperability. i.e. Vendor A and B must support ANY JMS provider.
 
 
Peter

________________________________

From: public-soap-jms-request@w3.org
[mailto:public-soap-jms-request@w3.org] On Behalf Of Phil Adams
Sent: Thursday, May 22, 2008 2:38 PM
To: Amelia A Lewis
Cc: SOAP/JMS (list)
Subject: RE: [SOAP-JMS] minutes 2008-05-20



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. 

In order to test a conforming implementation, the robotic
"conformance-checking" message consumer (for example) could receive the
JMS message, and (using the JMS API) could retrieve the various
properties from the JMS message and verify that they are set correctly,
etc.     But that does not, in and of itself, require the conforming
implementation to call specific JMS APIs in order to produce such a
request message, does it?        If the "conformance-checking" message
consumer were to use the JMS API to validate the request message sent by
the implementation's message producer component (client runtime), it
would be validating the message from the JMS API standpoint and would
not be validating things at the wire-format level, right? 

Maybe the fact that we're disagreeing on this somewhat basic issue is an
indication that we (as a group) need to precisely define what we mean by
"SOAP/JMS Interoperability" :) 

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




Amelia A Lewis <alewis@tibco.com> 
Sent by: public-soap-jms-request@w3.org 

05/22/2008 12:30 PM 

To
Phil Adams/Austin/IBM@IBMUS 
cc
SOAP/JMS (list) <public-soap-jms@w3.org> 
Subject
RE: [SOAP-JMS] minutes 2008-05-20

	





On 2008-05-22 12:10:14 -0400 Phil Adams <phil_adams@us.ibm.com> wrote:
> Well, does the SOAP/JMS spec really dictate which JMS APIs must be 
> called by 
> a conforming runtime?    It specifies, as an example,  the set of 
> properties 
> that must be set on the JMS message and the associated behavior, etc. 
> but it 
> doesn't say which APIs must be called by the conforming 
> implementation to 
> achieve that, nor should it in my opinion.

I have to disagree.

While vendors may supply other APIs to manipulate information provided 
by their implementation, including the API-level information, the 
*only* definition that we have, interoperably, is via the 
published/standardized JMS API.

Consequently, manipulation of JMS Headers and Properties is, defacto, 
reference to specific JMS API methods.  It can't be anything *but* 
that, because that's the only bit that we all agree to interoperate 
over.

Complexity kills.  It might be nice to have a conformance suite that 
(somehow, via configuration/environment/command line switches/magic) 
adapts to the proprietary extensions of each implementation, but we 
*cannot specify that*.  I mean, IBM could, for their stuff, and Sun 
for theirs, and TIBCO for ours, but the only thing that we all agree 
on is JMS API.

Consequently ... our conformance suite ought do *everything* related 
to JMS via JMS APIs.

If our specification of SOAP/JMS is not defined via the JMS API, then 
it isn't defined, interoperably.

> The reason being that some 
> implementations might not actually use the official JMS API to 
> construct 
> these messages.      The messages themselves are the interoperability 
> point 
> and not the actual APIs that were called to produce and consume them, 
> right?

Absolutely *not*.  Only the API is defined.  "Message" here presumably 
means wire format, in some fashion; that's *undefined* for JMS (each 
vendor has a specification, certainly, but I don't believe that there 
are two vendors who share one).

If it doesn't mean wire format, what does it mean?  If we're basing 
our specification on the definition of message, where is that 
definition specified?  I contend that it's only specified via the JMS 
API specification, which means, effectively, via JMS API calls.

Amy!
-- 
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
alewis@tibco.com