Fw: Proposed resolution for Issue 50 (Misallignment of faut to and reply to )

Forwarding David's answer to my mail of yesterday...

----- Forwarded by Francisco Curbera/Watson/IBM on 03/04/2005 09:21 AM
-----
                                                                                                                                  
                      David Hull                                                                                                  
                      <dmh@tibco.com>          To:       Francisco Curbera/Watson/IBM@IBMUS                                       
                                               cc:                                                                                
                      03/03/2005 02:29         Subject:  Re: Proposed resolution for Issue 50 (Misallignment of faut to and reply 
                      PM                        to )                                                                              
                                                                                                                                  




Francisco Curbera wrote:
      David,

      I don't understand your point. Who defines this binding? The deployer
      of
      the service receiving the message? This is the opposite of the model
      we
      have now, where the sender specifies where replies/faults should go.
      This
      is the base for supporting asynch communication.  Are you proposing
      that
      the receiver make this decision instead?

I had in mind things like the SOAP request/repsonse MEP (Section 6.2 in
SOAP 1.2 adjucnts).  This says that if you use SOAP for request/reply, the
service sends the reply back to the requestor.  The SOAP/HTTP binding
(Section 7 in the same document) says how to accomplish this over HTTP.  A
similar binding might say how to do it over SMTP, and this had better
default to the from: address.

Thinking aloud a bit, and please correct me if I'm mangling the SOAP spec
here  ...

So if I used WSA in a SOAP 1.2 request, and there was no Reply-To: MAP, the
usual SOAP sementics would apply, and the reply would come back to the
requestor.  The SOAP binding specifically says that the fault becomes the
OutboundMessage, which (as I read it) will be delivered to the
ImmediateDestination (that is, back to the sender) if possible.

On the other hand, if I gave a specific reply-to, then that reply-to would
become the immediate destination, and everything would work fine.  I'm not
sure, however, whether the async group reached the same conclusion.

On yet another hand, though, if I also gave a specific fault-to: different
from the reply-to: then it doesn't look like we have SOAP request/reply
anymore, as that MEP has no concept of a separate fault address.  I'm not
sure we've dealt with that.  Our SOAP binding doesn't cover SOAP MEPs as
far as I can tell.

In any case, the high order bit is that we (and possibly other parties)
will need to clarify what it means to do MEPs using WSA.  As part of that,
we can take two approaches w.r.t. reply-to and fault-to:
      Ensure that reply-to: and fault-to: always default to "back to the
      sender" and encourage future binding writers to do so.
      Explicitly make no useful guarantee as to how they default,
      effectively requiring them.
The latter would require some means of explicitly saying "use the return
channel" in cases where it's available, which I think is where "anonymous"
comes in.

In the former world, a missing reply-to:/fault-to: means "send it back to
the requestor".  Bindings over inherently one-way transports would have to
do extra work in order to support request/reply.  Alternatively, they could
simply not support it.  I would be fine with seeing a generic request/reply
over one-way binding using WSA, but maybe I'm missing something.

I the latter world, a missing reply-to:/fault-to: means "all bets are off",
but you can still ask for "send it back to the requestor" by explicitly
saying "anonymous".  Again, I'm not sure what this gains.

I'm hoping at least some of this makes sense ...

      The question here is what is the "right" default endpoint for sending
      faults back. Defaults should capture common and safe assumptions, not
      arbitrary choices. IMO the only reasonable default is replyTo because
      there
      you positively know that the sender is ready to accept a message;
      everything else is dangerous speculation. Defaulting to anonymous is
      risky
      because anonymous may not have any meaning for an arbitrary request.
      If the
      request message specifies that the reply be sent to a new endpoint,
      it
      seems unlikely that the sender would intend faults to be returned
      synchronously over the same connection.

      Anonymous seems like a badly chosen default to me. As for the binding
      dependent approach I just don't get it, sorry if I am being thick.

      Paco




                            David Hull

                            <dmh@tibco.com>                 To:
      public-ws-addressing@w3.org

                            Sent by:                        cc:
      "public-ws-addressing@w3.org" <public-ws-addressing@w3.org>

                            public-ws-addressing-req        Subject:  Re:
      Proposed resolution for Issue 50 (Misallignment of faut to and
                            uest@w3.org                      reply  to )



                            03/01/2005 09:00 PM






      Having thought it over, I still prefer this formulation:
            Bindings MAY define a default destination for faults and/or
      replies.
            A missing ReplyTo or FaultTo is interpreted according to the
      binding.
                  E.g., SOAP/HTTP defaults both to the backchannel.
                  something over email might default one or both to the
      From
                  address.
                  other bindings may require both always to be present --
      results
                  are undefined otherwise
            You could also use the anonymous endpoint designation to
      explicitly
            to invoke this default behavior, if you like that sort of
      thing.
            Sort of a "this page intentionally left blank".  But if there
      is no
            semantic difference between missing and anonymous, I'm not sure
      what
            anonymous is bringing to the party.
      We could also make the over-arching rule that a missing FaultTo
      defaults to
      the ReplyTo (which may in turn default as above), but I'm not sure
      this is
      a good idea.  For example, what does it mean for robust out-only,
      where
      there may be a fault but will not be a reply?  It would also
      interfere with
      bindings that have naturally different destinations for faults and
      replies.  I can't name such a binding, but I'm not willing to say it
      can't
      exist.

      Tom Rutt wrote:

            As currently specified, an EPR is allowed to have th value
            “anonymous” for the wsa:ReplyTo element. In this case, the
      reply goes
            back to the sender over the HTTP response, just as if not using
            addressing.

            I would like to have an optimization (just as we did for
      wsa:To) that
            absence of wsa:ReplyTo is semantically equivalent to using the
            “anonymous” value.

            Also: we almost agreed to have missing FaultTo implying use of
            ReplyTo when a fault is to be sent.

            Proposal to resolve Issue 50:

            First cut at text to add to the spec in definition of
      wsa:ReplyTo:
            “
            In the case of a message for which a reply is expected, the
      implied
            semantics of wsa:ReplyTo not present are equivalent to it being
            present with the anonymous URI.
            “

            In the definition for wsa:FaultTo, add the statement:
            “
            If wsa:FaultTo is absent, a Fault may be sent to the value
      (explicit
            or through the implicit indication of “anonymous”) for
      wsa:ReplyTo..

Received on Friday, 4 March 2005 14:22:40 UTC