Some issues with request/response binding to sync/async transport .

Hi. 
XML Protocol requirements document does include use cases that cover
multihop, request/response, RPC, asynchronous messages, and multiple
responses so this note is relavent. 

One thing that is missing in SOAP (and SOAP derivatives like SOAP with
attachments, BIZTALK, ebXML, etc) is 
proper support (atleast in my opinion) for sync/async BEHAVIOR
(request/response). 
 
SOAP says: 
"Processing a message or a part of a message requires that the SOAP
processor understands, among other things, the exchange pattern being used
(one way, request/response, multicast, etc.), the role of the recipient in
that pattern, the employment (if any) of RPC mechanisms such as the one
documented in  <http://www.w3.org/TR/SOAP/#_Toc478383532> section 7, the
representation or encoding of data, as well as other semantics necessary for
correct processing."

So request/response behavior indication is not defined in SOAP headers. 

XML Protocol has not defined what request/response and asynchronous
messaging means (as far as I can see). Let me try out some definitions as
straw map ideas. I dont know what the industry accepted definitions are. 

A sync behavior (request) is basically defined by the sender and understood
by the receiver. The sender app thread that 
want the sync behavior sends a message and blocks for a response (or error)
with possible timeout. A receiver app thread 
implements a sync behavior by responding (typically immediately) in the
thread that received the request.
 
In an async behavior the sending thread does not wait for a response. One or
more response may be received later and 
processed by a different thread. The receiving thread does not need to
respond in that thread.   
 
A sync transport allows a response to be optionally sent back in the same
transport session. 
 
An async transport does not allow this. The response has to be sent back in
a seperate transport session possibly many days later.   
 
There is confusion between sync/async transports and sync/async behaviors
(called request/response). These two are
completely independent, although a protocol may define a transport binding
that maps the behavior to the transport. You
CAN implement a sync behavior on top of an async transport (like a MOM or
SMTP) or a sync transport (like HTTP).
Conversely you CAN implement a async behavior on top of a sync transport or
an async transport. Also you can
use different types of transports over different hops and still preserve the
sync or async behavior. Also the request 
may use one transport type and the response may use another transport type
vre a hop. 
 
However there are problems for the various threads everywhere in determining
if they should block for a reply. Also the end
point has difficulty in determining the behavior to implement. 
 
1. There is not a defined way for a sender to notify a receiver that the
sync behavior is required. The receiver has to know 
    out of band that this request type is a sync request. I dont see why
this should be the case. I also dont see why 
    the same request type cannot be requested with sync or async behavior.
2. When a sync request is mapped to a sync transport into an intermediate
(or endpoint) node over a hop, the recv thread 
    in that node has to know to block for the response (for both sync or
async transport out of this node over the next hop). 
    It can only know this if there was some indication in the header that
this is a sync request. If the outgoing transport is
    async, the response has to have an indication that this is a syncreply
so the blocked thread can pick it up (message
    matching done through some correlation fields in headers). The blocked
thread might have timed out in which case the
    indication that this is a sync reply is a clue that the message has to
be discarded.

Received on Friday, 18 May 2001 16:30:20 UTC