RE : RE : Action-56

Peter,
thanks for caring; my answers below
___________________________________________
Jacques.Talbot@teamlog.com  Mobile: 06 07 83 42 00
________________________________


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



I rephrase what you say below, to be sure we are talking about the same thing, especially since the word "transport" is ambiguous (is it SOAP or HTTP/JMS or TCP ?); we can distinguish, I believe, three levels of asynchronicity:



I use below a Request Reply MEP and the Java world for examples of implementations



1 - Asynchronous as seen from the programmer : there are two variants

  1.1- asynchronicity simulated in the toolkit: only one synchronous SOAP exchange; this is of little interest for real world long term asynchronous MEPs, since the HTTP transport time-outs after a while, and the server side is not aware of the asynchronicity. This can be done without WSA, with SOAP on any binding. This use case is more or less out of the perimeter in a WSA/SOAPonJMS discussion.

  1.2 - asynchronicity at the SOAP level : this is often called asynchronous on the wire. Request and reply are 2 different SOAP exchanges. In axis2, there is a is wireasync boolean to require this mode. In CXF, there is an equivalent DecoupleEndpoint option. This setup requires WSA management at the protocol level on both ends.



2 - asynchronous at the SOAP level : this is necessary to implement 1.2. This level of asynchronism is visible to the WS toolkit programmer, and even to the programmer using the WS toolkit.



3 - asynchronous at the SOAP binding level : this is not possible with the SOAP on HTTP binding because HTTP is inherently synchronous; however it is possible and even mandatory with the JMS binding since Request and Reply are bound to 2 different queues. But this level of asynchronism is hidden to the toolkit programmer by the binding layer.  So it is of no use to the programmer willing to program long term asynchronicity. The only benefit is the enhanced reliability provided by JMS (assuming BTW that the appropriate QoS is actually mandated by the binding)



Summarizing, the interesting use case is an Asynchronous Request Reply MEP with an "asynchronous on the wire" toolkit option; in this context,  we should explain the differences between the 2 bindings; this is what I tried to do.



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.

It depends which transport we are taking about:

- WSA is required to handle SOAP transport level asynchronicity

- WSA is not needed if we talk about HTTP/JMS level asynchronicity.



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.

There are 2 ways to improve reliability:

1 - use a more reliable binding (read JMS) and configure appropriately the JMS QoS options

2 - use an ureliable binding (read HTTP) and WS-RM

3 - for paranoids, WS-RM on top of SOAP/JMS is recommended, since there are obviouly some failures modes that are not covered by 1 and 2  :-)

 Also, SOAP on JMS is not really an option in B2B due to JMS not being a protocol and therefore preventing ineroperability.



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.