- From: David Hull <dmh@tibco.com>
- Date: Fri, 08 Apr 2005 15:16:28 -0400
- To: David Orchard <dorchard@bea.com>
- Cc: public-ws-async-tf@w3.org
- Message-id: <4256D88C.3060200@tibco.com>
David Orchard wrote:
> I think this is good work, where you are going. It certain is similar
> to the work that I published. There are some unanswered questions though.
>
Thanks. I've deliberately tried to stay as close as possible to
existing work that I know of, in the belief that most of the hard
analysis has already been done and we just need to pull it together. In
particular, I've seen your proposal for SOAP one-way. I've also looked
through your recent blog entry and I intend to put together a full
response/commentary, after due pondering. Can you point me at any other
related work that hasn't appeared on either WSA or this list in the last
couple of months? I want to compare notes as we may well be very close
(i.e., I may be very close to catching up).
>
>
>
>
> 1. Should there be an in-optional-out or in-optional-fault or both
> soap meps? I'm leaning towards in-optional-fault because I think that
> the SOAP MEP layer needs to be self-describing wrt responses, and I
> don't see any value in an in-optional-out where the out could be not a
> fault. The logic for HTTP:
>
> - One-way: http response codes ignored, sender/receiver know that
> response body can't be generated.
>
> - Request-response: http response codes relevant: 2xx indicates a SOAP
> BODY response, 4/5xx indicates SOAP FAULT response, 404 indicates no
> SOAP BODY or FAULT response. Senders and receivers know whether to
> wait or not depending on the status code.
>
> - In-optional-fault: http response codes relevant, FAULT only in 4/5xx
> (excluding 404). Sender and receiver know exactly what can be sent.
>
I tend to lean the other way. I see a fault response on the [fault
endpoint] (or back-channel as the case may be) as basically just another
message and the SOAP transport doesn't really have to know anything
about it. That distinction is made at the WSDL MEP level,
notwithstanding that SOAP calls out faults as a special kind of
message. On the other hand, a transport fault, as indicated by a 4/5xx
is something that the SOAP transport sees directly and must report
specially.
So in the case of one-way over HTTP, the SOAP layer ought to report a
404 as a transport fault -- you tried to send this message, but I know
for a fact that it didn't arrive because the party on the other end had
never heard of the URL you were trying to POST to. I don't see this as
materially different from trying to connect to the HTTP server and
finding out that the named host doesn't exist or isn't accepting
connections on the port in question. On the other hand, one-way over
HTTP doesn't really care whether a 200 or 202 or 204 comes back, while
in-[out] cares deeply.
In the case of in-[out], a 200 would indicate a returned message
(whether reply, fault, or something else that some exotic MEP produced),
204 would indicate definitely no message (but the MEP is complete),
4/5xx would indicate a transport fault, and other codes (e.g. 202 and
3xx) are open to further discussion as to which of those three bins they
go into.
I'm not 100% sure how this view accords with the existing description of
SOAP request/reply. As I recall, it's deliberately vague about how
faults are dispatched.
>
>
> The problem with in-optional-out instead of in-optional-fault, is that
> the MEP is dynamic, that is a sender and receiver won't know ahead of
> time whether they will send a response or not. The fault cases are
> covered by the in-optional-fault, so the in-optional-out only affects
> the responses. Whether a response is expected for a 2xx status code
> can be known by the sender and receiver - and you've shown how it's
> known for the various configurations of ReplyTo.
>
To be clear, I'm arguing for the SOAP layer to be entirely blind to the
endpoint MAPs and for the MEP selected (or a configuration parameter on
an über MEP) to indicate whether a reply is expected/required. I
believe this is sufficient to support everything we really need, given
that the transport bindings for in-[out] MUST provide a way to tell that
the MEP is complete and whether a message or nothing or a transport
fault came back.
>
>
> 2. I proposed the "allowAnonymous" with default=true on the ReplyTo.
> I propose that this be added to your proposal and it be updated.
>
Does this mean that, by default, a service advertising WSA compatibility
would accept "anonymous" as a [{reply,fault, whatever} endpoint] with
the same "return to sender" semantics as currently defined for missing
properties, but it could also explicitly say "I don't handle anonymous
endpoints"? If so, this seems like a perfectly good example of Postel's
principle and I'm fine with it. We might then want to point out
explicitly that you MUST NOT use "anonymous" in the context of a pure
one-way transport.
If it means something else, I may still be fine with it, but I'll need
to get my head around it before saying so.
>
>
> Cheers,
>
> Dave
>
>
>
> ------------------------------------------------------------------------
>
> *From:* public-ws-async-tf-request@w3.org
> [mailto:public-ws-async-tf-request@w3.org] *On Behalf Of *David Hull
> *Sent:* Friday, April 08, 2005 9:14 AM
> *To:* public-ws-async-tf@w3.org
> *Subject:* MEPS Part II: SOAP
>
>
>
> Following on to the previous proposal for WSDL MEPs, here is what I
> think we will need at the SOAP layer to make everything play
> together. This may also help clarify a couple of phrases in the
> previous proposal, namely " if the binding defines a default means of
> delivering outbound messages" and "there will have been enough
> information in the WSDL binding to detect the situation". Again, this
> is largely a synthesis of ideas we've already discussed. For me, the
> key point is that it looks like we really have identified all the
> pieces we need, and they can be made to fit together.
>
> For the sake of concreteness and since most of the discussion has
> revolved around in-[out], I'll cast what follows in terms of three
> MEPs (in-only, in-[out] and the existing request-reply), but the same
> general approach would work with a single configurable "über MEP".
> This approach is built around a fairly simple case analysis. One of
> these cases will always hold:
>
> * The sender doesn't care what comes back directly to it.
> * The sender expects a return message under some circumstances,
> and needs to know either that such a message arrived or
> definitely won't arrive.
> * The sender expects a return message under all circumstances.
>
> In all cases, even the first, there may be transport faults.
>
> These three cases obviously correspond to in-only, in-[out] and
> request-reply respectively. The first case is valid on /any/
> messaging protocol. The last two apply only when the messaging
> protocol is capable of sending return messages to the sender without
> the assistance of a [reply endpoint] MAP or similar device. HTTP can
> support all three cases. An email binding might or might not support
> all three depending on how it's defined. A pure pub/sub protocol
> could only support the first. In all cases, the binding definition
> will say what MEPs are supported, so a potential client can know ahead
> of time whether in-[out] and request-reply are available.
>
> The obligations for the transport layer follow directly from these cases
>
> * In in-only, the transport is obligated only to send the message
> (or report a transport fault).
> * In in-[out], the transport is obligated to send the message and
> report whether a return message was sent (or report a transport
> fault)
> * In request-reply, the transport is obligated to send the message
> and deliver a return message (or report a transport fault).
>
> Here is how the WSDL MEPs and related variations layer on top of the
> three SOAP MEPs:
>
>
> *Request/Reply*
>
> * If both [reply endpoint] and [fault endpoint] are defined (note
> 1), use in-only.
> * Else if the binding in use only supports in-only, then [reply
> endpoint] and [fault endpoint] MUST be defined. You just can't
> do request/reply over a fire-and-forget transport without saying
> where you want replies and faults to go.
> * Else if the binding in use supports in-[out] and request-reply, then
>
> o If exactly one of the two is defined (note 1, note 2), use
> in-[out].
> o If none is defined, use request-reply.
>
> Note 1: I'm assuming no anonymous endpoints here. If we allow these,
> then an anonymous reply or fault endpoint has the same effect as if
> the property were undefined.
>
> Note 2: The "[fault endpoint] defaults to [reply endpoint] if
> possible" rule can apply here if we want. I left it out as it
> complicates the text but doesn't really change the picture.
>
>
> *Robust In-Only*
>
> As before, this is just a reduced form of the request/reply case
>
> * If [fault endpoint] is defined (note 1), use in-only.
> * Else if the binding in use only supports in-only, then [fault
> endpoint] MUST be defined. You just can't do robust in-only
> over a fire-and-forget transport without saying where you want
> faults to go.
> * Else if the binding in use supports request-reply and [fault
> endpoint] is not defined, use request-reply.
>
>
> *In-only*
>
> * Use in-only
> * And that's it
>
>
> *Other patterns (e.g., request/reply/alternate,
> initial/normal/urgent etc.)*
>
> Again, the service advertising such a service can set any contract it
> likes and define whatever properties it likes. However, the rules
> given above extend smoothly to other patterns, with the modifications
> shown in bold, because the SOAP MEPs themselves don't look at the [*
> endpoint] properties. Note that the previous rules fall out as
> special cases (including in-only, since the first condition is
> vacuously true). :
>
> * If *all possible endpoints for further messages* are defined
> (note 1), use in-only.
> * Else if the binding in use only supports in-only, then* all
> possible endpoints for further messages* MUST be defined. You
> just can't do *such an interaction *over a fire-and-forget
> transport without saying where you want *further messages* to go.
> * Else if the binding in use supports in-[out] and request-reply, then
>
> o If *some but not all possible endpoints for further
> messages are defined *(note 1, *note 2 does not apply*),
> use in-[out].
> o If none is defined, use request-reply.
>
>
>
Received on Friday, 8 April 2005 19:16:37 UTC