Some notes on the Request-Response MEP, prompted by asynchronicity

I should prolly copy the xmlp and wsarch groups on this, but we'll start 
here, since wsdesc is talking about MEPs right now.

Let us say, for the sake of argument, that I want to set up a binding for 
a web service that runs over Joe Random Protocol (otherwise known as JRP 
(note: this is simply a made-up name for an example, because the actual 
protocol doesn't matter; only its characteristics matter)).

JRP is asynchronous.  That is, for the purposes of this discussion, it is 
not possible, in JRP, to send the response back over the same open socket 
that was used to deliver the request.

So let's think about the consequences:

1. Where do I, as the service, send my response?
2. What do I need to do in order to associate this particular response 
with that particular request?
3. How long do I have to respond?
4. As a client, how long should I wait before I decide that I'm not going 
to *get* an answer?

One notes that the SOAP 1.2 Request-Response MEP does not answer any of 
these questions explicitly.  It is, in fact, designed for use with HTTP.  
Here are the answers for HTTP:

1. The other end of the open socket.
2. If necessary, create a key from the server:port/client:port tuple.  But 
the client will know that the response received on the open socket is 
associated with the request sent on the open socket.
3. Depends on the stack.  As long as the socket stays open.
4. Until the socket closes; depends on the stack.

Or, in other words, the protocol binding can answer all these questions, 
for a synchronous protocol.  The questions become a little more open over 
JRP.

1. JRP has addressing conventions.  Typically, each message contains a 
source address.  It *may* contain a response address.  Either the protocol 
binding or the service is going to have to specify how the priority is 
worked out.  In this case, maybe we can specify it in the protocol: 
response addr if it exists, source otherwise.

2. JRP has an optional message ID mechanism.  We'd better require it.  
Moreover, we also have to require the message reference mechanism.  So 
every request will have an ID, and every response will have both an ID and 
a reference ID which identifies the request message.

3. Ouch.  I don't think that a protocol binding can specify this.  Looks 
like we need to ask those nice people at wsdesc how one can represent a 
message timeout per-operation (or between any two messages in an operation?
).  Maybe a service could set a default?  But it isn't reasonable for the 
JRP binding to establish timing; it's going to be at least 
service-dependent, and prolly operation-dependent.

4. As in 3.  It sort of needs to be in the WSDL, doesn't it, so that the 
client can know when to give up.

More generally, of course, we can speak of the "termination conditions" 
for a particular exchange pattern.  Time is almost always one of those, 
although it often represents an abnormal termination (but not a very 
exceptional one, given reliability issues with the network).

I thought that this would be worth mentioning now, as the wsdesc group 
starts thinking of abstract MEPs.  A whole collection of "abstract" MEPs 
that have implicit ties (like SOAP Request-Response) to a synchronous 
protocol won't really help those of us who want to try to develop bindings 
for other protocols.  And we're likely to let people share our unhappiness 
....

Amy!
--
Amelia A Lewis
Architect
TIBCO/Extensibility
alewis@tibco.com

Received on Thursday, 23 January 2003 10:47:52 UTC