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

Hi Eric,
Good description of the various pieces of the puzzle...

Looking at your diagram, let's suppose  that "C" represents the "client 
runtime" and "G" represents the "server runtime".      "A" would represent 
a client application that is trying to interact with application "I" in 
some way (i.e. "I" could be a web service that's housed in a Java EE 
container, for example).    You may not have intended for your diagram to 
be that specific, but let's just label it that way for the sake of 
discussion.     At a minimum, I think we have to test "C" and "G".     "C" 
would have to conform to the "Requesting SOAP Node" requirements described 
in the spec and "G" would have to conform to the "Responding SOAP Node" 
requirements.      A vendor will likely have an implementation that 
includes both "C" and "G" (i.e. both the client and server runtime 
components).      So, I think we agree on basically *where* the testing 
should occur.    The question might just be *how* we test for conformance. 
     Amy suggested that we test C and G at the JMS API level to ensure 
that C and G call the "correct" JMS APIs.    And I think I'm suggesting 
that instead of doing that, we should test C by inserting a mocked up impl 
of G that would receive the JMS message produced by C and verify it (by 
using the JMS APIs to retrieve properties from the message and verify the 
values, etc.).      Likewise, I'm suggesting that we should test G by 
providing a mocked up impl of C that produces messages that are then 
received by G and processed.    C would receive reply messages from G (for 
two-way operations at least) and would verify them (again by using the JMS 
APIs to retrieve properties, etc.).

If two conforming implementations need to interoperate, they would at 
least need to use the same JMS provider.   So, for example, C could be 
provided by vendor1, and G could be provided by vendor2.   And D and F 
need to be the same JMS provider (I'm not considering the case where we 
bridge between two messaging engines... that's cheating :) ).        In 
this situation, we could independently test vendor1's and vendor2's 
conformance using the approach above and that would ensure that vendor1's 
impl of C and vendor2's impl of G would interoperate, assuming that they 
are using a common JMS provider.        I'm not sure what we're saying 
relative to the selection of JMS providers and whether vendors need to be 
able to run with any JMS provider, etc... but I would think that any sort 
of compliance statement made by a vendor would include a discussion of the 
particular JMS providers upon which their implementations will run.

I think we're agreeing more than we're disagreeing here, unless of course 
I mis-interpretted your diagram :) 

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




Eric Johnson <eric@tibco.com> 
Sent by: public-soap-jms-request@w3.org
05/22/2008 03:59 PM

To
Amelia A Lewis <alewis@tibco.com>, public-soap-jms@w3.org
cc

Subject
Re: [SOAP-JMS] minutes 2008-05-20






Hmmm, I've been puzzling over this, trying to figure out what the right 
answer is, as the messages scroll by.

Naturally enough, I pretty much agree with my co-worker Amy.  The only way 
we can test conformance is via the JMS APIs.  I think this discussion has 
accidentally veered into quite interesting territory - as near as I can 
tell, we may not be arguing about *how* to test conformance, per-se, but 
about *where* we test for conformance, or, more formally, what are the 
conformance targets of the specification?

Doing a really bad ASCII diagram, suppose my use case is a Java service 
using SCA or JAX-WS to send a message to a remote SCA or JAX-WS Java 
client, using SOAP over JMS.

(A)Applicaton --> (B)data binding layer --> (C)SOAP processing stack --> 
(D) JMS provider client -->  (E) JMS server --> (F) JMS provider client 
--> (G) SOAP processing stack --> (H) data binding --> (I) Application

If I follow this correctly, I believe Phil is arguing that we test for 
conformance between (F) & (G), and only there.  Whereas, I think Amy and 
(now) I are arguing that we should also test between (C) & (D).

I think there are two reasons for this.  One reason comes from an 
assumption hidden above, which is that there may not be any step (G).  
We've gone through great pains in the specification to make certain 
characteristics of a SOAP message visible as properties of the message 
itself, so, for example, listeners could set up filters on the server 
looking for certain properties on the message.  So testing for conformance 
at "F" is actually too late - by the time that a message has arrived at 
"F", the properties already need to be set on the message.  However, since 
everything that happens between entering (D), and leaving (F) is 
proprietary, we have no way to test what goes on there.

The second problem comes from the notion of a conforming SOAP stack - does 
it get to make assumptions about using extensions to the JMS API?  That 
is, do we expect that the conforming SOAP stack will need to work with 
*any* JMS provider, so almost by definition, the only portable way it can 
work is via straight JMS APIs.  We can postulate the existence of a SOAP 
stack that happens to know how to take advantage of some proprietary 
extension from vendor X, maybe for performance or security or some such 
thing.  Just for a completely made-up example, I could extend the JMS API 
to somehow "secure" the value of the properties that I set on a message, 
but to do so, I have to call a vendor API, not one of the standard ones.

If that's the kind of scenario that Phil is trying to address, I that 
leaves us with a question.  When we test at the point between C & D, how 
do we do it?  I can think of three approaches:
Write a "mock" JMS provider - messages never go anywhere, but can be 
checked for correctness
Write a JMS provider that wraps another JMS provider with pure JMS APIs.
Extend the above with the use of dynamic proxies, so that we can pass 
along calls to proprietary methods to the underlying implementation.
Require SOAP stacks going through conformance testing to provide a hook, 
whereby the message they're about to send can be checked.
The first two approaches would prevent any conformance test target from 
detecting and using extension APIs, and thus would verify, even for a 
vendor that happens to support extensions from specific providers, that 
they would also happen to be conformant.  I also came to the conclusion 
that the dynamic proxies approach would likely be complicated, and 
probably still fail.  The wrapped JMS provider approach might work, but 
I've not considered the scope of work there.  The "hook" approach would be 
straightforward, but it intrudes on the SOAP/JMS provider stack.

-Eric.

Phil Adams wrote: 

Ok, I might be in the minority here, and that's fine if I am... but I 
disagree that we should be dictating the actual API calls that should be 
invoked in the JMS API by a conforming implementation.    If you want to 
talk about the fact that a conforming implementation should add string 
property "A" to the request message and that the values for "A" should be 
X/Y/Z/whatever, then that's fine, but I don't think it's correct to say 
that the conforming implementation MUST call the 
javax.jms.Message.setStringProperty("A",<value>) method within the JMS API 
layer to set the value.    I'm not taking this position because my 
implementation doesn't use the JMS API (in fact it does use it), but I 
know of other implementations that might want to "conform" but do not use 
the JMS API per se. 

In order to test a conforming implementation, the robotic 
"conformance-checking" message consumer (for example) could receive the 
JMS message, and (using the JMS API) could retrieve the various properties 
from the JMS message and verify that they are set correctly, etc.     But 
that does not, in and of itself, require the conforming implementation to 
call specific JMS APIs in order to produce such a request message, does 
it?        If the "conformance-checking" message consumer were to use the 
JMS API to validate the request message sent by the implementation's 
message producer component (client runtime), it would be validating the 
message from the JMS API standpoint and would not be validating things at 
the wire-format level, right? 

Maybe the fact that we're disagreeing on this somewhat basic issue is an 
indication that we (as a group) need to precisely define what we mean by 
"SOAP/JMS Interoperability" :) 

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 12:30 PM 


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









On 2008-05-22 12:10:14 -0400 Phil Adams <phil_adams@us.ibm.com> wrote:
> Well, does the SOAP/JMS spec really dictate which JMS APIs must be 
> called by 
> a conforming runtime?    It specifies, as an example,  the set of 
> properties 
> that must be set on the JMS message and the associated behavior, etc. 
> but it 
> doesn't say which APIs must be called by the conforming 
> implementation to 
> achieve that, nor should it in my opinion.

I have to disagree.

While vendors may supply other APIs to manipulate information provided 
by their implementation, including the API-level information, the 
*only* definition that we have, interoperably, is via the 
published/standardized JMS API.

Consequently, manipulation of JMS Headers and Properties is, defacto, 
reference to specific JMS API methods.  It can't be anything *but* 
that, because that's the only bit that we all agree to interoperate 
over.

Complexity kills.  It might be nice to have a conformance suite that 
(somehow, via configuration/environment/command line switches/magic) 
adapts to the proprietary extensions of each implementation, but we 
*cannot specify that*.  I mean, IBM could, for their stuff, and Sun 
for theirs, and TIBCO for ours, but the only thing that we all agree 
on is JMS API.

Consequently ... our conformance suite ought do *everything* related 
to JMS via JMS APIs.

If our specification of SOAP/JMS is not defined via the JMS API, then 
it isn't defined, interoperably.

> The reason being that some 
> implementations might not actually use the official JMS API to 
> construct 
> these messages.      The messages themselves are the interoperability 
> point 
> and not the actual APIs that were called to produce and consume them, 
> right?

Absolutely *not*.  Only the API is defined.  "Message" here presumably 
means wire format, in some fashion; that's *undefined* for JMS (each 
vendor has a specification, certainly, but I don't believe that there 
are two vendors who share one).

If it doesn't mean wire format, what does it mean?  If we're basing 
our specification on the definition of message, where is that 
definition specified?  I contend that it's only specified via the JMS 
API specification, which means, effectively, via JMS API calls.

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