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

This sounds good. 
I don't think that the App Server environment changes anything in
The Web Service Tester(s) two of them right ? one being a Web Service
consumer(i.e. driving requests and checking the response); the other a
consumer (receiving and checking requests and responding) could be
standalone JMS apps - there's no need for the tester to be in an App
Server container(its not like we're testing XA etc). 


[] On Behalf Of Phil Adams
Sent: Thursday, May 22, 2008 11:44 AM
To: Amelia A Lewis
Cc: SOAP/JMS (list);; Roland Merrick
Subject: RE: [SOAP-JMS] minutes 2008-05-20

Hi Amy, 
Actually, what I was thinking about was...     Suppose we are trying to
test the compliance of a vendor's client runtime component (message
producer).   In that case we need to have a way to drive the function of
the client runtime so that it will, in fact, produce SOAP/JMS messages
that can be checked for compliance.      One way to do this, perhaps, is
to supply some sort of web service application that will need to be
deployed, installed, and executed on the vendor's runtime.    This would
cause the client portion of the runtime to deliver JMS messages to a
destination queue or topic.     Another part of this test might be a
"conformance-checking" message receiver that would receive messages off
the queue or topic and inspect them for correctness (verify that all the
correct properties are specified, and the correct standard JMS headers
are set correctly, etc.).    So, in this situation, we're essentially
putting the vendor's client runtime under the microscope to ensure that
it is behaving correctly from a SOAP/JMS protocol standpoint.      I
don't think we want to start examining things at the JMS API level since
we're not dictating what APIs a conforming runtime must use; instead,
the SOAP/JMS spec is dictating what the JMS messages must look like. 

We could also extend this concept to the message receiver component as
well, I think.   The "conformance-checking" app could be simply a mocked
up message producer that simply sends messages to a destination queue or
topic and verifies that it receives the correct replies, etc.    And I
think this would also require a web service application to be installed
on the vendor's runtime to ensure that the message receiver component
was in fact, working correctly. 

Of course, my thinking here is restricted to the application server
environment, since that's what my focus is.   There might be other
"runtimes" out there that want to play in the SOAP/JMS sandbox as well
that would operate differently and might have different testing

I agree that we should probably not try to do a "WS-I" like interop test
where a standard application is deployed on various vendor runtimes and
the endpoints are made publicly available.     I don't think that makes
sense in a JMS type environment.    Instead, to address "conformance"
requirements we should probably adopt a more "CTS"-like approach where
the test applications consist of a set of web services and various
clients, along with a bootstrapping component that would allow the test
suite to be deployed and installed on the vendor's runtime (the
bootstrapping component would define plug-points that would need to be
implemented by each vendor to account for differences in how
applications are deployed and installed in their runtime).   This is
sort of how the Java EE CTS is structured now. 

Phil Adams 
WebSphere Development - Web Services
IBM Austin, TX
office: (512) 838-6702  (tie-line 678-6702)
mobile: (512) 750-6599

Amelia A Lewis <> 
Sent by: 

05/22/2008 09:15 AM 

Phil Adams/Austin/IBM@IBMUS 
Roland Merrick <>, SOAP/JMS (list)
RE: [SOAP-JMS] minutes 2008-05-20


[snipped attachments]

On 2008-05-22 09:52:16 -0400 Phil Adams <> wrote:
>> "or perhaps we should develop two components, a "conformance checkin
> responder app" and a "conformance checking  requesting app" that 
> simpldrive 
> the binding implementations."
> That's one of the options I was referring to on Tueday's call.      
> We could 
> develop those "conformance-checking apps" to verify each side of the 
> producer/consumer "connection", and - at least in the case of where 
> we're 
> verifying the compliance of the vendor's message producer component 
> (i.e. 
> client runtime) - we'd also need to develop some sort of web service 
> application that exercises the client runtime and causes the desired 
> messages to be produced by that client runtime, etc.

Errrrrmmmmmm.  Complexity kills.

I'd recommend a minimalist approach, insofar as that is possible.  
Some principles:

1) we define against an API.  Consequently any supplied code
   a) should use the API
   b) should not use the SPI
   c) should minimize use of any components outside the SDK

2) as I understand it, JMS is rarely deployed outside the firewall
   a) is that a misconception?
   b) if it is not, then are we going to be able to deploy a public 
   c) security, security, security ...

3) do we need a deployed application?
   a) see (2)
   b) implementors may prefer (strongly) to do internal conformance 
testing before exposing their work to others (particularly true of 
JMS, where the proprietary tradition is quite strong)

This leads me in the direction of suggesting not a web application or 
public endpoint, but a downloadable conformance suite.

If standard JMS API calls + can produce a "common serialized 
format" from messages, I would recommend that we investigate doing 
this.  The format would presumably contain not only the JMS message 
body, but also headers/environmental information.  Conformance testing 
would then involve: hooking up this serializer, and running a 
comparison utility against the messages.  Modules sender, receiver, 
serializer, verifier.  Data would then be a standard set of messages, 
and the rules for verifying conformance.

This may be what you're suggesting.  If so, please forgive my 

> Phil Adams WebSphere Development - Web Services
> IBM Austin, TX
> email:
> office: (512) 838-6702  (tie-line 678-6702)
> mobile: (512) 750-6599
> Roland Merrick <> Sent by: 
> 05/22/2008 08:19 AM
> To
> "Peter Easton" <>
> cc
> Subject
> RE: [SOAP-JMS] minutes 2008-05-20
> Greetings Peter, off to a quick start!
> I have NOT worked my way through it all yet but you make it clear 
> that we 
> will have to think about a testing/conformance framwork of some kind 
> as well 
> as the tests. The framework will have to examine the JMS Messages to 
> ensure 
> that they conform. How should we do this? I do not know. We could get 
> a hook 
> into the requestor and responder or perhaps we should develop two 
> components, 
> a "conformance checking responder app" and a "conformance checking 
> requesting app" that simply drive the binding implementations.
> Regards, Roland
> IBM Software Group, Strategy, Software Standards
> "Peter Easton" <> 21/05/2008 21:48
> To
> Roland Merrick/UK/IBM@IBMGB, <> cc
> Subject
> RE: [SOAP-JMS] minutes 2008-05-20
> Here's a initial pass.  I started copying a lot of the core document 
> test, 
> then decided it was easier to just locally annotate the assertions 
> and 
> personal test comments as editorial comments to the spec, I suppose 
> we could 
> come up with "testernote" annotation . Nothing, of course, has been 
> checked 
> into cvs.  I haven't completed the WSDL Usage section nor looked at 
> the IRI 
> spec  Peter
>  From: 
> [] 
> On Behalf Of Roland Merrick
> Sent: Wednesday, May 21, 2008 9:42 AM
> To:
> Subject: [SOAP-JMS] minutes 2008-05-20
> ACTION: Peter and Phil will take a first pass of the spec to identify 
> assertions [recorded in 
> Regards, Roland

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

Received on Thursday, 22 May 2008 16:13:56 UTC