W3C home > Mailing lists > Public > public-ws-async-tf@w3.org > April 2005

Re: MEPS Part II: SOAP

From: Marc Hadley <Marc.Hadley@Sun.COM>
Date: Fri, 08 Apr 2005 14:52:31 -0400
To: David Orchard <dorchard@bea.com>
Cc: David Hull <dmh@tibco.com>, public-ws-async-tf@w3.org
Message-id: <acebdac229cf36a7b98711728032e7f5@Sun.COM>

On Apr 8, 2005, at 2:11 PM, 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. 
>
> 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 don't buy that 4/5xx indicates a SOAP Fault response. It *may* 
indicate that but it might equally indicate that something went wrong 
in my HTTP infrastructure *before* any SOAP processing occurred and the 
entity body could include some HTML error message.

Marc

>  
>
> 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.
>
>  
>
---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.
Received on Friday, 8 April 2005 18:52:35 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Friday, 8 April 2005 18:52:36 GMT