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].

RATIONALE
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 HTTP
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:
http://www.w3.org/TR/2004/WD-wsdl20-extensions-20040803/#in-out
or: http://tinyurl.com/4rsvz 
2. p2e:
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm#p2e
or: http://tinyurl.com/53hqp 
3. p2c:
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm#p2c
or: http://tinyurl.com/4pjo4 


-- 

David Booth
W3C Fellow / Hewlett-Packard

Received on Tuesday, 28 September 2004 22:21:10 UTC