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

Thanks Eric
 
That's clearer. See where you're coming from..
 
Yes, I would argue not to test selectors on the tester side for
simplicity, because at that point you are beginning to test your JMS
provider selector functionality and not the actual SOAP/JMS message
rendition requirements for which calls to getXYZProperty(...) are more
to the point. 
 
Probably circling here....
 
Peter

________________________________

From: Eric Johnson [mailto:eric@tibco.com] 
Sent: Thursday, May 22, 2008 7: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