RE: Message Exchange Patterns -- p2c and/or p2e

Thank you for your comment, tracked as LC50 [1].  The WG agreed to a
definition of "node" [2] which clarifies somewhat which node would be
appropriate for a given scenario.  You can see the resolution in the
latest Working Draft [3].

If we don't hear from you within two weeks, we'll assume this resolution
is satisfactory.


> -----Original Message-----
> From: [mailto:public-ws-desc-
>] On Behalf Of David Booth
> Sent: Tuesday, September 28, 2004 3:21 PM
> To:
> Subject: Message Exchange Patterns -- p2c and/or p2e
> As currently defined, the WSDL 2.0 in-out MEP[1] requires the service
> to
> send the response message back to the original requester agent, as
> illustrated by pattern p2e[2] in "MEPs versus IOPs".  (This is in
> contrast with pattern p2c[3], which permits the response to go to a
> third party.)
> I think the WG should either:
> 	a. Add a pattern like p2c[3] to the MEPs in part 2,
> 	   in addition to the existing in-out MEP;
> 	b. Replace the existing in-out MEP with a pattern like p2c[3].
> Suppose a service wishes to permit the response to be sent to a third
> party.  For example: requester agent A sends a request to service S,
> which sends the response to agent B (by use of an addressing
> extension,
> for example).  What should service S do, given that the semantics of
> the
> in-out MEP require the response to be sent back to A?  How should
> service S be described in WSDL?  It could:
> 	a. modify the semantics of WSDL 2.0 by use of a required
> 	   extension (wsdl:required = "true");
> 	b. use an MEP that is not pre-defined in WSDL 2.0, such as
> 	   p2c[3]; or
> 	c. violate the WSDL 2.0 specification.
> Pattern p2c[3] was considered earlier by the WG, when the WG discussed
> MEPs, and I think the main reasons for adopting p2e[2] instead were:
> 	- It captures the intent of many common interactions.
> 	- It permits a requester toolkit to generate code that
> 	supports a very simple, function-like usage style,
> 	independent of what binding is used:
> 	    Reply message = service.send(requestMessage);
> 	while not precluding an event-driven
> 	implementation style that would be needed by p2c[3].
> However, I believe two things have changed since the WG made that
> decision:
> 1. The WG became more permissive about the set of MEPs that it defines
> in Part 2, adding MEPS for additional fault treatments (Robust-In-
> Only,
> Robust-Out-Only) and optional responses (In-Optional-Out,
> Out-Optional-In).
> 2. The use of Web service addressing extensions is now receiving more
> attention.  For example, the W3C is now considering creating a Web
> services addressing WG.
> 3. A requester toolkit could have an option (for each operation) to
> generate code in the function-like usage style shown above, even if
> the
> service specifies pattern p2c[3], and it could even be the default
> option.  (In this case, the requester toolkit would hide the fact that
> A
> and B need not be the same in p2c[3].)  Others may correct my memory,
> but I don't think this possibility was considered at the time when the
> MEP TF was discussing the pros and cons of p2c versus p2e.
> Incidentally, one potential argument for adopting BOTH p2e[2] and
> p2c[3]
> is that p2e[2] also allows the *service* toolkit to optimize
> interactions because it knows that the reply always goes back to the
> same agent that sent the request.  For example, it permits a single
> interaction to transmit both the request and the response.  This is a
> further consideration that I don't remember discussing during the MEP
> TF.
> References
> 1. WSDL 2.0 in-out MEP:
> or:
> 2. p2e:
> iops/meps-vs-iops_clean.htm#p2e
> or:
> 3. p2c:
> iops/meps-vs-iops_clean.htm#p2c
> or:
> --
> David Booth
> W3C Fellow / Hewlett-Packard

Received on Thursday, 12 May 2005 20:52:22 UTC