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 
characteristics.

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
email: phil_adams@us.ibm.com
office: (512) 838-6702  (tie-line 678-6702)
mobile: (512) 750-6599




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

To
Phil Adams/Austin/IBM@IBMUS
cc
Roland Merrick <roland_merrick@uk.ibm.com>, SOAP/JMS (list) 
<public-soap-jms@w3.org>
Subject
RE: [SOAP-JMS] minutes 2008-05-20







[snipped attachments]

On 2008-05-22 09:52:16 -0400 Phil Adams <phil_adams@us.ibm.com> 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 
> SOAP 
> 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 
service?
    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 + java.io 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 
misunderstanding.

Amy!
> 
> Phil Adams WebSphere Development - Web Services
> IBM Austin, TX
> email: phil_adams@us.ibm.com
> office: (512) 838-6702  (tie-line 678-6702)
> mobile: (512) 750-6599
> 
> 
> 
> 
> Roland Merrick <roland_merrick@uk.ibm.com> Sent by: 
> public-soap-jms-request@w3.org
> 05/22/2008 08:19 AM
> 
> To
> "Peter Easton" <peaston@progress.com>
> cc
> public-soap-jms@w3.org
> 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
> FBCS, CITP
> IBM Software Group, Strategy, Software Standards
> 
> 
> 
> "Peter Easton" <peaston@progress.com> 21/05/2008 21:48
> 
> To
> Roland Merrick/UK/IBM@IBMGB, <public-soap-jms@w3.org> 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: public-soap-jms-request@w3.org 
> [mailto:public-soap-jms-request@w3.org] 
> On Behalf Of Roland Merrick
> Sent: Wednesday, May 21, 2008 9:42 AM
> To: public-soap-jms@w3.org
> Subject: [SOAP-JMS] minutes 2008-05-20
> 
> 
> http://www.w3.org/2008/05/20-soap-jms-minutes.html
> ACTION: Peter and Phil will take a first pass of the spec to identify 
> assertions [recorded in 
> http://www.w3.org/2008/05/20-soap-jms-minutes.html#action01]
> 
> Regards, Roland
> FBCS, CITP

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