RE: i028: Implications of the presence of ReplyTo (and also i003: )

Tom: I must say I concur that using message header elements such as ReplyTo
for enabling MEPs "larger" than WSDL operations (that is what the charter
requires I think)
brings lots of benefits. 

But then that implies that the presence of ReplyTo should be completely
decoupled from WSDL operation types, and driven by whoever describes these
larger MEPs.
and I am surprised that Gudge proposed it to be mandatory in the input of
WSDL request-responses (i003).

I think Tom's use case is a valid one, but makes precisely the case for
decoupling ReplyTo from WSDL operation types (I modified slightly the case
to match a RosettaNet PIP): 

Purchasing dept: -- P.O. --> WS (with a ReplyTo in the input of a
Request-response)
Purchasing dept: <-- receipt -- WS (that would be the output of a
Request-response)
business unit: <-- PO AcceptanceOrRejection -- WS (previous ReplyTo refers
to Business unit)

in the case above, the use of ReplyTo is orthogonal to the nature of WSDL
MEP involved. Could as well be a One-way if the Receipt was not needed.

Jacques



-----Original Message-----
From: Martin Gudgin [mailto:mgudgin@microsoft.com]
Sent: Friday, November 12, 2004 9:59 AM
To: tom@coastin.com
Cc: Marc Hadley; public-ws-addressing@w3.org
Subject: RE: i028: Implications of the presence of ReplyTo



 

> -----Original Message-----
> From: Tom Rutt [mailto:tom@coastin.com] 
> Sent: 12 November 2004 17:17
> To: Martin Gudgin
> Cc: Marc Hadley; public-ws-addressing@w3.org
> Subject: Re: i028: Implications of the presence of ReplyTo
> 
<SNIP/>
> I really think we all need to understand each other's 
> requirements for 
> ws:addressing.
> 
> With my purchase order example, the address to send the 
> future invoice 
> to (in a subsequent and separate MEP) belongs
> as "application" data.   Thus it should be in the WSDL input message, 
> bound to the body in the soap binding.

And I want people to be able to build protocols this way. That's a
reasonable choice. Other people might choose to use the [reply
endpoint]. We should allow both design styles.

Gudge

<SNIP/>