[Fwd: Re: Proposed text for async]

I inadvertently sent this to Marc point-to-point.

Forwarded message 1

  • From: David Hull <dmh@tibco.com>
  • Date: Fri, 18 Nov 2005 14:17:07 -0500
  • Subject: Re: Proposed text for async
  • To: Marc Hadley <Marc.Hadley@Sun.COM>
  • Message-id: <437E28B3.8060601@tibco.com>
Marc Hadley wrote:

> I'm a bit unclear on the difference between "N.2 Anonymous response 
> endpoint not used" and "Non-anonymous response endpoint used". In 
> particular we require a [reply endpoint] if the MEP indicates that a 
> response should be expected so I wouldn't expect in-out to fall under 
> N.2 at all, it would either be N.1 or N.3. What am I missing ?

In in-out, if the [reply endpoint] is null ([address] is ..../none),
then no reply is to be given, so neither anonymous nor non-anonymous
would be used.  With in-only and robust in-only, this will be the
typical case.

N.2 talks about handling the inbound message.  If you're not using
anonymous, that is, if you're not doing a request-response, then you
treat the inbound message as a one-way, according to your transport.

N.3 talks about handling the outbound message.  If you're not using
anonymous, but you /are/ sending an outbound message, then treat it as a
one-way, according to your transport.

Given that N.2 and N.3 both apply to the non-anonymous case, they could
be combined.  I kept them separate because:

    * Not all cases requiring N.2 require N.3 (i.e., pure in-only,
      robust in-only with no fault, in-out with null response endpoint
      just require N.2).
    * One could define MEPs where /both/ N.1 and N.3 apply, but N.2
      doesn't.  E.g., a request always triggers a "reply" and a "log
      message", with one endpoint anonymous and one not.  I'm not
      claiming this is likely, but both we and WSDL at least hold open
      the possibility.
    * N.2 and N.3 potentially apply to different transports.  E.g., with
      HTTP in and email out, N.2 says "make sure the HTTP interaction is
      one-way (i.e., send back 202)" while N.3 says "send the reply
      one-way (i.e., send an email)." Separating the rules makes it
      easier to make this distinction (i.e. "transport of the endpoint"
      vs. the ever-so-subtly-different "transport of the EPR in
      question").  I hope.

I think this formulation is somewhat better factored than a combined
version, but I'm more concerned with the rules themselves than their
presentation.

BTW, I think N=5.3, most likely.

>
> Marc.
>
> On Nov 14, 2005, at 12:18 PM, David Hull wrote:
>
>> This may or may not be behind the "don't go there" door.  However, 
>> it is short, it requires no changes to the SOAP adjuncts beyond the 
>> already agreed addition of a SOAP one-way MEP, and I believe it 
>> unambiguously defines what to put on the wire for the various 
>> combinations of MEP and endpoint, assuming only that there is some 
>> way to determine the transport binding for a given response EPR 
>> (that last item lying behind a different door we decided not to open).
>>
>> In particular, it defines clearly what we mean by the anonymous 
>> endpoint.
>>
>> N. Binding of WSDL MEPs to transport The following rules define the 
>> required handling of [reply endpoint] and [fault endpoint], 
>> collectively referred to as response endpoints, in the context of 
>> the WS-Addressing SOAP binding, when WS-Addressing is engaged.
>>
>> In what follows
>> A response endpoint is used if it is the destination of a message 
>> belonging to the WSDL MEP of the operation being invoked.
>> An endpoint is anonymous if its [address] is the anonymous endpoint 
>> defined in section 2.1 of the WS-Addressing core.
>> An endpoint is null if its [address] is the "none" endpoint defined 
>> in section 2.1 of the WS-Addressing core.
>> N.1 Anonymous response endpoint used
>> If an anonymous endpoint is used, then the entire operation MUST 
>> comply with the SOAP request-response MEP defined in section 6.2 of 
>> the SOAP adjuncts, as bound to the transport of the endpoint.
>> NOTE: In the context of the currently defined WSDL 2.0 MEPs, this 
>> will occur in the following cases:
>> robust in-only, if a fault is produced and the [fault endpoint] is 
>> anonymous.
>> in-out, if a normal reply is produced and the [reply endpoint] is 
>> anonymous.
>> in-out, if a fault is produced and the [fault endpoint] is anonymous.
>> N.2 Anonymous response endpoint not used If no anonymous endpoints 
>> are used, whether because none are present or because there is no 
>> message with such an endpoint as a destination, the delivery of the 
>> inbound message of the operation MUST comply with the SOAP one-way 
>> MEP (to be defined), as bound to the transport of the endpoint.
>> NOTE: In the context of the currently defined WSDL 2.0 MEPs, this 
>> will occur in the following cases:
>> in-only
>> robust in-only, if no fault is produced
>> robust in-only, if a fault is produced but the [fault endpoint] is 
>> not anonymous
>> in-out, if a normal reply is produced but the [reply endpoint] is 
>> not anonymous
>> in-out, if a fault is produced but the [fault endpoint] is not 
>> anonymous
>> N.3 Non-anonymous response endpoint used If a non-anonymous, non-
>> null EPR is used as the destination of an outbound message, the 
>> outbound message MUST comply with the SOAP one-way MEP (to be 
>> defined), as bound to the transport of the EPR in question.
>> NOTE: In the context of the currently defined WSDL 2.0 MEPs, this 
>> will occur in the following cases:
>> robust in-only, if a fault is produced and the [fault endpoint] is 
>> not anonymous and not null.
>> in-out, if a normal reply is produced and the [reply endpoint] is 
>> not anonymous and not null.
>> in-out, if a fault is produced and the [fault endpoint] is not 
>> anonymous and not null.
>> NOTE: In the case of a robust in-only operation MEP with an 
>> anonymous [fault endpoint], or the case of an in-out MEP where one 
>> response endpoint is anonymous and the other is not, either rule N. 1
>> or rules N.2 and N.3 will apply depending on the outcome of the 
>> operation.  For this reason, bindings for transports which support 
>> both the SOAP one-way and request-response MEPs must be defined in 
>> such a way that the inbound message handling is identical for both 
>> MEPs, and the sender can determine that the operation has completed 
>> whether or not the anonymous endpoint is used.
>>
>> NOTE: In the case of the SOAP/HTTP binding, the WS-Addressing 
>> working group will assume, for the purposes of testing, that the 
>> SOAP one-way MEP consists of the request half of the existing 
>> request-response MEP together with an HTTP 202 response containing 
>> an empty SOAP envelope.
>
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> Business Alliances, CTO Office, Sun Microsystems.
>
>

Received on Friday, 18 November 2005 21:27:30 UTC