- 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 UTC