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

testing strategies: summary and open issues

From: Amelia A Lewis <alewis@tibco.com>
Date: Wed, 18 Jun 2008 12:23:31 -0400
Message-ID: <8bda53a37cb2d35dc43a4924fd2a4cb8@xerom.na.tibco.com>
To: SoAP/JMS (list) <public-soap-jms@w3.org>


Okay, Phil, Eric, Roland and I have been engaged in trying to work out 
a strategy that we all agree upon, with some, but not complete 

The chief area where we are incompletely in agreement is in how to 
"instrument" testing.  JAX-WS does not provide access to underlying 
transports; consequently, testing for JAX-WS based implementations 
seems as though it may need to be restricted to "opposite side".  That 
is, we would supply a bare-JMS implementation that lives on the 
service side, and evaluate the messages received from the service 
consumer, or a bare-JMS implementation that lives on the consumer 
side, and evaluate the messages received from the service.  Another 
option proposed was that we write a JMS SPI (without a network 
component), and hook up vendor stacks on top of that SPI 
implementation.  Feedback and comments (or an alternative solution!) 
would be very valuable, here.

In terms of evaluating the messages, we seem to be largely agreed that 
we can define (via some form of XML schema; I can supply a draft of a 
Relax-NG schema on request) 'message' in its context, corresponding to 
javax.jms.Message and the interesting surrounding bits.  Each test 
case then is composed of one or more instance documents representing 
the messages in canonical form.  A Java implementation of 
"MessageParser" would be able to generate canonical form of a message 
from javax.jms.Message and friends.  A MessageComparator (if needed) 
would then verify that they match.

This covers the SOAP-only implementations, which is one profile.  That 
leaves us to test SOAP+WSDL implementations.  Here, it is suggested 
that what we do is examine the messages produced by a stack 
provisioned with a WSDL (so, effectively, we re-use the testing 
technologies outlined above).  Cheap, easy, reuses effort, and 
separates the SOAP from SOAP+WSDL profiles.

Phil, Eric, Roland ... if we need clarification, or if I've misspoken, 
please speak up.

Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
Received on Wednesday, 18 June 2008 16:24:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:17:19 UTC