Re: Issue 130: Asynch request/response HTTP binding needed

On Thu, 24 Jun 2004 16:06:58 +0100
paul.downey@bt.com wrote:
>   2) a MEP is implemented using a transport which doesn't 
>      provide a return path for a receiver to communicate 
>      with the sender, or the return path isn't back to 
>      the original sender.

> Case (2) requires an addressing mechanism to be carried in the 
> message contents - WS-Addressing, WS-MessageDelivery or some such.

At the moment, the only in-out MEP in part two specifies that the out
message is sent to the node that sent the in message.  "third-party
request/response" has been mooted, but no one has written it up or
suggested that it needs to be in.

The difference would be that it would specify three nodes in the
interaction: in from some node {inode} to the {service} node, out from the
{service} node to some node {onode}.

onode MAY be identical to inode, but the current specification of in-out
REQUIRES that identity.  How that identity is achieved is left to the
binding.

> So, sadly, "say nothing" sounds like the most pragmatic route for 
> this WG, and all i have to do now is work out how to break the bad 
> news to my colleagues.

I agree.  In order to specify this fully, we need the third-party r/r MEP,
then a binding of that MEP in one of the bindings that we define.  Of the
two bindings we are publishing, neither comfortably matches this pattern. 
We do have MEPs in part two that are not used in part three, though
(because folks have asked for them); this one could be added (but if a
"dynamic in-out" of the sort described above, if added to part two, would
*not* specify *how* the onode is identified; that's left to {some
binding}).

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

Received on Thursday, 24 June 2004 11:19:33 UTC