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