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

Group,

 

It seems the least invasive way to test the conformance of the sender is
to capture the message at point F.  What is the added value in testing
between C and D?  Why exactly are we bringing message selectors into
this discussion?  A message selector will have no impact on the content
of the message.

 

Regards,

Derek

 

________________________________

From: public-soap-jms-request@w3.org
[mailto:public-soap-jms-request@w3.org] On Behalf Of Eric Johnson
Sent: Thursday, May 22, 2008 6:05 PM
To: Peter Easton
Cc: Amelia A Lewis; public-soap-jms@w3.org
Subject: Re: [SOAP-JMS] minutes 2008-05-20

 

Hi Peter,

Peter Easton wrote: 

Hi Eric,

 

Obviously I'm not getting something basic here - so please bear with me.


 

Are you are talking about JMS 1.1 message selectors? If so, who in this
case is setting the selector ?

 

In this setup the tester at F is a pure JMS client that had better be
listening on the right destination with no restrictive selectors. 

I think you're circling right back to the question of conformance
targets.  We have written the specification so that it is *possible* to
use message selectors (my apologies for not using the JMS terminology
earlier) to select which messages are delivered to which listeners.  In
other words, we have to test the conformance of the sender, and the
conformance of the recipient.

Maybe what you're saying is simply this.  Suppose that we do start
throwing message selectors in the mix.  You're suggesting:

*	it is possible to write a system that fully tests the
conformance of the sender, because we can always write pairs of opposing
selectors, guaranteeing that the message is always delivered to
something in our test harness - thus giving us something to test?
*	Doing that would be easier than trying to test the sender at the
point where the message has been sent.

Maybe you're not making this last point, but that would be something for
us to explore.

-Eric.



 

Peter

 

________________________________

From: Eric Johnson [mailto:eric@tibco.com] 
Sent: Thursday, May 22, 2008 5:52 PM
To: Peter Easton
Cc: Amelia A Lewis; public-soap-jms@w3.org
Subject: Re: [SOAP-JMS] minutes 2008-05-20

Hi Peter,

Peter Easton wrote: 

Eric can you explain this. Are you saying the JMS Server is removing JMS
properties before client delivery at F ?

Sorry, I thought the context of using "Filters" made this statement
clear.  What I mean is that when filters are applied, the server may
never deliver the message to (F), because (E) determines that (F) isn't
wanting to see the message.  If we had a well-defined way to check the
message either as it arrives at (E) the server, or while it is at
server, this wouldn't be a particularly big deal.  Of course, JMS
doesn't give us that, though, which means that we can only check the
message as or before it is delivered to (D).

-Eric.



 

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

 

 

________________________________

From: public-soap-jms-request@w3.org
[mailto:public-soap-jms-request@w3.org] On Behalf Of Eric Johnson
Sent: Thursday, May 22, 2008 5:00 PM
To: Amelia A Lewis; public-soap-jms@w3.org
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> <mailto: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> <mailto: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>
<mailto: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