RE: RE : RE : Action-56

Jacques,

 

Good points, I don't think there is any disagreement here. For sure
there are additional patterns (e.g. one-way with callback) by which
asynchronous operations can be implemented over transports like HTTP and
JMS. You mention SOAP 1.2, note that Request-Response and One-Way are
the only mandatory patterns for SOAP/JMS support.

 

The original scope of the question focused on the WS-Addressing
relationship to SOAP/JMS which I have described. The asynchronous QOS
aspect that WS-Addressing can provision to HTTP is mentioned as being
something that JMS can inherently do. That's the only additional
observation that I am making. 

 

 

Peter

 

________________________________

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