RE: RE : Action-56

Jacques,

 

Thanks for the feedback. This has got me thinking further...

 

When we talk about "synchronicity", there are two places where this can have meaning: at the transport, and at the programming model.

 

For example, you mention JAX-WS. JAX-WS supports an asynchronous invocation model that is independent of the transport synchronicity. For example, you can program JAX-WS asynchronously but the underlying transport is synchronous HTTP request-response (WS-Addressing present or not). If I understand it correctly, I disagree with your statement that programming synchronicity model depends on the transport synchronicity model, and further, that WS-Addressing is needed for transport asynchronous operation.

 

When we talk about high end class of service, it seems to me that an application developed with an asynchronous or event driven programming model, in conjunction with an asynchronous and reliable transport leads to highest quality.  HTTP is inherently unreliable and synchronous. I'm of the opinion that this is why we have WS-Addressing and WS-ReliableMessaging. On the other hand, JMS is inherently asynchronous and offers better reliability options. To me, this is what is compelling about SOAP/JMS.

 

This is what I was alluding to by the statement "prevents the more asynchronous implementation that JMS is conducive of". I can try and spell this out a bit more.

 

Regarding:  "with the JMS binding, these two items must be JMS URIs as described in document "

 

Strictly, if you are using WS-Addressing there is nothing in the specifications to prevent you sending a request over JMS, and requesting the fault (or response) to be delivered over a different transport. Of course in practice, implementations that leverage these features might have issues working with their programming model, or interoperating with other implementations.

 

Thanks



Peter

 

________________________________

From: TALBOT Jacques (TJA) [mailto:Jacques.TALBOT@teamlog.com] 
Sent: Wednesday, January 14, 2009 4:28 AM
To: Peter Easton; public-soap-jms@w3.org
Subject: 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.