RE: Some issues with request/response binding to sync/async trans port .

Hi adam. 

Your example expands the use case to where the sender insists on using sync
RPC
and the receiver insists on using async RPC or vice versa. I made the
assumption 
that the receiver will match what it does to the sender specified
instruction
(sync or async RPC) and has no freedom to insist on anything. In my
suggestion, 
the intermediary has no state or knowledge of any kind and strictly reacts
to 
message header instructions to do mappings (only RPC mesage type to
configured 
transport type). A sync RPC reply can be tagged since this is true end to
end since 
a sync RPC reply is in response to a sender specified sync RPC request. This
tagging 
is usful information.

One field can be used which could take 3 values. 

1. sync RPC request. 
2. sync RPC reply. 
3. async oneway request. (async RPC is done with multiple oneway messages). 
  

-----Original Message-----
From: Dr Colin Adam [mailto:colin.adam@webservices.org]
Sent: Friday, May 18, 2001 2:59 PM
To: Kasi, Jay; xml-dist-app@w3.org
Subject: RE: Some issues with request/response binding to sync/async
transport . 




This discussion topic interests me, so I hope you won't mind me making some
points which I think are useful.

First, I will use the term asynch or synch RPC, to relate to whether a
webservice operates asynchronously or synchronously at the application
layer. I am only concerned with the application layer.

Can I just go back to basics for a moment. Say one webservice (sender) which
wishes to call another (receiver), it must have an understanding of whether
the "other" webservice operates asynchronously, synchronously or has the
ability to deal with both (assuming it knows somehow to distinguish the
nature of the incoming request). That information must be know at outset,
before the sender sends a message to be ensured of success.

That is fair enough, but I envisage that a single webservice, can by choice,
be able to handle both asynch and synch RPC. It can switch. To allow this
the sender message must contain a flag to say which RPC method it expects
the communication to use.

There is also the possibility that an intermediary webservice could "allow"
an asynch RPC webservice to work with an synch one, by being the intelligent
"connection" in the middle.
This intermediary would therefore have to know the RPC methods of both
webservices, so we would have two flags then. Each message would state its
RPC method, plus the RPC method of the webservice it is trying to call. This
would allow the intermediary to convert.

However, I don't think we need two flags. There is only need for one, and a
lookup table

for example

flag 1. sender is synch. optional indicator to intermediary that receiver is
synch
flag 2. sender is asynch. optional indicator to intermediary that receiver
is asynch
flag 3. sender is synch. receiver is asynch. need intermediary conversion
flag 4. sender is asynch. receiver is synch. need intermediary conversion

just some ideas.



-----Original Message-----
From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
Behalf Of Kasi, Jay
Sent: Friday, May 18, 2001 21:30
To: 'xml-dist-app@w3.org'
Subject: 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 18:18:01 UTC