W3C home > Mailing lists > Public > public-soap-jms@w3.org > May 2008

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

From: Amelia A Lewis <alewis@tibco.com>
Date: Thu, 22 May 2008 13:30:16 -0400
Message-ID: <969d087748d0f238a5057cbbd7134012@xerom.local>
To: Phil Adams <phil_adams@us.ibm.com>
Cc: SOAP/JMS (list) <public-soap-jms@w3.org>

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
Received on Thursday, 22 May 2008 17:31:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:16:17 GMT