an attempt to clarify, re: testing


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.

Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.

Received on Friday, 23 May 2008 14:52:55 UTC