Re: an attempt to clarify, re: testing

Greetings Amy, looks like there was lots of messaging going on last night 
that I was blissfully unaware of until I got in this morning!

I think I agree with what you written below. There are multiple messaging 
systems that support a variety of apis with multiple language bindings. 
The scope of the SOAP-JMS Binding is to define a SOAP binding to a 
transport that exposes capability through a JMS api. We should be testing 
that an implementation of such a binding correctly implements the spec of 
binding to the JMS api. This is the essence of the difference between SOAP 
binding to HTTP (a transport) and SOAP binding to JMS (an api).

We have not, at least till now, specified that a particular JMS api MUST 
be used to set/retrieve a JMS header property. I had assumed that if there 
are multiple ways of doing this then any are allowed as long as the 
declared objective of setting/retrieving the property is achieved. Perhaps 
my assumption is wrong and that there is only one way or that even if 
there is more than one way that we should be prescriptive about which way. 


Regards, Roland
FBCS, CITP
IBM Software Group, Strategy, Software Standards



Amelia A Lewis <alewis@tibco.com> 
Sent by: public-soap-jms-request@w3.org
23/05/2008 15:52

To
SOAP/JMS (list) <public-soap-jms@w3.org>
cc

Subject
an attempt to clarify, re: testing







Heyo.

Okay.  Here's the tarpit that I would suggest we need to avoid.  I'm 
going to use my own company's products as an example.

TIBCO EMS provides a "C++ binding".  That is, TIBCO EMS has, in 
addition to the JMS API and SPI, a library which exposes functions 
suitable for calling from C++ code.  Call these in the correct order, 
with the proper bits and bobs, and you can send and receive 
information that passes over TIBCO EMS provider.

My argument, basically, is that the C++ binding is out of scope, even 
if a Java sender can generate the messages that a C++ client consumes, 
or a C++ client can generate the messages that a Java client consumes. 
  It should be perfectly clear that C++, no matter what the functions 
look like, is not a *Java* Message Service.

Similarly, I know that various language bindings exist for our and our 
rivals' providers.  Again, I wish to rule them out of scope for 
conformance testing by fiat.

This has consequences for how we construct a conformance/test suite. 
It suggests that the line ought to be "JMS API".  Period.  That is, 
just as other languages are not "SOAP over the JMS API", so custom 
vendor application interfaces are not "SOAP over the JMS API", *even 
if they are Java interfaces and classes.*

This is not to suggest that a vendor "must not" provide alternative 
implementations.  It is simply a statement that *those* 
implementations are not, and cannot be regarded as, conformant.

Stated another way: TIBCO has a wire-level format, and a message 
definition at that level.  JMS doesn't; it has a Message interface (a 
Java object).  We can validate, for conformance, anything that 
manipulates Message, but something that manipulates message (even if 
it produces, in a particular environment, the identical binary blob), 
is out of scope.  If TIBCO provides alternative APIs that produce a 
message which is a valid Message ... irrelevant.  Likewise if TIBCO 
provides alternative APIs that bypass Message to consume message. 
TIBCO can, if we provide the JMS stuff, claim conformance to SOAP/JMS 
for the JMS stuff, but *not for the alternative APIs*.  Well, we could 
*claim*, but we should not expect to have validation of the claim. 
The claim (and its reservations and qualifications) are our (TIBCO's) 
problem, not our (this working group's) problem.

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









Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU