W3C home > Mailing lists > Public > public-soap-jms@w3.org > August 2008

Re: WS-Addressing

From: Phil Adams <phil_adams@us.ibm.com>
Date: Wed, 6 Aug 2008 09:44:07 -0500
To: Mark R Maxey <Mark_R_Maxey@raytheon.com>
Cc: public-soap-jms@w3.org, public-soap-jms-request@w3.org
Message-ID: <OFAA6A79B2.E0DD5F41-ON8625749D.004F8327-8625749D.0050F264@us.ibm.com>
Hi Mark,
With regard to using WS-Addressing along with SOAP/JMS, there's no 
guarantee that a SOAP/JMS-conforming runtime will support WS-Addressing.  
In fact, there may be some vendor runtimes that support the SOAP/JMS spec, 
but are not what we would normally think of as web service runtimes, and 
so it would not make sense for them to support WS-Addressing per se. 

Having said that, I don't believe that the SOAP/JMS spec is in conflict 
with WS-Addressing at all.     If a sending SOAP node (i.e. runtime that 
supports the web service consumer) sends out a SOAP request message to a 
JMS destination, the spec requires that the JMSReplyTo header is set to 
the destination where the reply message should be sent.    This would be 
"equivalent" to the WS-Addressing "replyToEPR" value in the SOAP header. 
In other words, the replyToEPR value would be a jms-style endpoint URL 
string that refers to the reply destination.     Although I don't think 
this particular scenario has been discussed in the SOAP/JMS working group, 
I suppose if the WS-Addressing component running in the sending SOAP node 
wants to specify an HTTP-based replyToEPR, then it would be up to the 
runtime to *not* set the JMSReplyTo value in the JMS request message 
(since the reply will not be sent to a JMS destination), and the receiving 
SOAP node would need to honor the replyToEPR value in the WS-Addressing 
SOAP header.

If the SOAP request message contains a faultTo value in the WS-Addressing 
SOAP header, then the receiving SOAP node (i.e. runtime that supports the 
web service provider/endpoint) should support that if it is in fact 
conforming to WS-Addressing.    But I don't see that the SOAP/JMS spec 
should necessarily discuss that.     The fact that the vendor runtime 
might also support WS-Addressing in addition to SOAP/JMS is an issue which 
is seperate and distinct from the SOAP/JMS spec itself, IMHO.

Phil Adams 
WebSphere Development - Web Services
IBM Austin, TX




From:
Mark R Maxey <Mark_R_Maxey@raytheon.com>
To:
public-soap-jms@w3.org
Date:
08/06/2008 08:48 AM
Subject:
WS-Addressing




I've tried to follow the WS-Addressing discussion, so I'm sorry if I'm 
rehashing old ground ... 

Did anyone consider leaving some properties abstract in this document and 
creating other documents with concrete mappings to JMS headers & 
WS-Addressing?  Is there going to be a addendum or note that speaks to 
WS-Addressing? 

I'd like to see clear direction on what to do when using WS-Addressing 
header with SOAP/JMS.  There's ambiguity and overlap to be addressed. 
WS-Addressing also includes some metadata not available via JMS, e.g., 
FaultTo. 

Perhaps I'm misguided, but I thought the beauty of SOAP was that the same 
message could be sent over HTTP or JMS without modification.  That concept 
is broken if one is forced to use protocol specific metadata.  I would 
like to see a SOAP/JMS or SOAP/HTTP where properties of protocols are 
configured via the WSDL,  web services infrastructure "binds" to protocols 
at the transport layer, and the creation and processing of message content 
is 100% based on the XML SOAP payload.  This allows web service 
implementations to minimize the amount of protocol specific code. 


Cheers,
Mark Maxey
Received on Wednesday, 6 August 2008 14:45:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:16:17 GMT