RE : Action-56

Peter et als,

since I am the one who opened up this WSA issue, I try to make some suggestions below to make this "tutorial" easier to grasp for the average WS user.
My perspective is that we should assume that this person is familiar with SOAP on http and the usage of WS-Addressing with SOAP on http.
We should then describe the differences when SOAP is bound on JMS in sync and async MEPs.
We are in the FAQ, so nothing should prevent you to think out of the SOAPonJMS box :-)

Thanks

___________________________________________
Jacques.Talbot@teamlog.com  Mobile: 06 07 83 42 00
________________________________
De : public-soap-jms-request@w3.org [public-soap-jms-request@w3.org] de la part de Peter Easton [peaston@progress.com]
Date d'envoi : mardi 13 janvier 2009 21:04
À : public-soap-jms@w3.org
Objet : Action-56

Here’s my proposal for a FAQ entry, comments welcome.

Peter


What is the relationship between SOAP/JMS and WS-Addressing?

Web Services Addressing provides transport-neutral mechanisms to address Web services and messages. At its core, WS-Addressing defines abstract properties to aid in the referencing of Web Service endpoints, constructing of message flows, correlation, and message identification. WS-Addressing is intended to work over any SOAP underlying protocol binding including SOAP/JMS. Over SOAP, behavior is described in terms of the abstract Message Exchange Patterns<http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#soapmep> (MEPs) that a given binding supports. Addressing properties are conveyed in the form of SOAP headers. These properties are distinct from the transport properties specified at the JMS property level.

The SOAP/JMS binding provides both one-way and request-response MEPs. Otherwise the SOAP/JMS binding imposes no constraints on the use of Web Services addressing.

WS-Addressing provides a number of features. Some of these features are useful where the underlying transport lacks equivalent capability. For example, over HTTP, in the absence of WS-Addressing, SOAP faults and responses must be returned on the HTTP response. This holds the transport resources open for the duration of the exchange and prevents the more uncoupled, asynchronous implementation that JMS is conducive of. From a WS-Addressing perspective, the HTTP response provides the transport “back-channel” for MEP responses and faults. WS-Addressing uses the anonymous URI to specify the transport “back-channel”. In the case of SOAP/JMS it is the JMS ReplyTo and JMSCorrelationID that defines the transport “back-channel” for WS-Addressing. That is the extent of the relationship, for example, there is nothing in the SOAP/JMS binding that imposes equivalencies between WS-Addressing correlation properties and those for JMS correlation.



If we compare the behavior between the HTTP and JMS bindings in various situations, some differences appear:

 1 - Synchronous request response
This can programmed without WS-Addressing, or with WS-Addressing and the anonymous URI to specify the transport “back-channel”.
 - with the HTTP binding, the response and faults are returned on the HTTP back-channel
 - with the JMS binding, the JMS ReplyTo and JMSCorrelationID define the transport "back-channel”.
Usually, the Web Services toolkit library will hide the differences between the 2 bindings, and the programming can be the same. (Correct ?)



It is unlikely in this use case that request response correlation is needed. However, if the WS-Addressing MessageID is used by the programmer for such purpose,  there is nothing in the SOAP/JMS binding that imposes equivalencies between WS-Addressing MessageID and JMS JMSCorrelationID . This decision is left to the JMS binding implementation and/or the WS toolkit.



2 - Asynchronous request response
This must be programmed with WS-Addressing above the SOAP layer.
Notice that despite the fact that JMS has some intrinsic asynchronous properties, the usage of the SOAP on JMS binding brings nothing from this standpoint compared to the SOAP on HTTP binding.
- with the HTTP binding, the programmer specifies the response port wsa:ReplyTo and optionally the error port wsa:FaultTo. Address are http URIs.
- with the JMS binding, these two items must be JMS URIs as described in document ???.
Depending on the WS toolkit capabilities (e.g. JAX-WS), the peculiarities of such an endpoint will be more or less hidden from the programmer.
There is nothing in the SOAP/JMS binding that imposes equivalencies between WS-Addressing ReplyTo and JMS ReplyTo.



In this use case, request response correlation is usually needed. The WS-Addressing MessageID is used by the programmer for such purpose; but there is nothing in the SOAP/JMS binding that imposes equivalencies between WS-Addressing MessageID and JMS JMSCorrelationID . This decision is left to the JMS binding implementation and/or the WS toolkit.

__________________________

You get the idea: provide some help to the poor programming soul across the layers:  JAX-WS, WSA, SOAP on JMS. BTW, I am not reallysure I have properly described the options above.

Similar explanations could be provided for one-way MEPs.