RE: MEPS Part II: SOAP

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.  

 

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.

 

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.

 

2. I proposed the "allowAnonymous" with default=true on the ReplyTo.  I propose that this be added to your proposal and it be updated.

 

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

	*	If exactly one of the two is defined (note 1, note 2), use in-[out].
	*	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

	*	If some but not all possible endpoints for further messages are defined (note 1, note 2 does not apply), use in-[out].
	*	If none is defined, use request-reply.