W3C home > Mailing lists > Public > xml-dist-app@w3.org > December 2005

[Fwd: Toward more fully-formed options]

From: David Hull <dmh@tibco.com>
Date: Wed, 14 Dec 2005 12:14:00 -0500
To: xml-dist-app@w3.org
Message-id: <43A052D8.6020900@tibco.com>


attached mail follows:


First, here are some basic facts I believe we are trying to account for:

   1. An HTTP interaction always consists of a request message and a
      response message, though neither need contain a SOAP envelope. 
      There may be other transports (actual or anticipated) with the
      same behavior.
   2. There are transports (actual or anticipated) which are inherently
      fire-and-forget.  In such a case, a request-response MEP must be
      built from one-way messages (using, say, WSA).
   3. Depending on the WSDL MEP and response endpoints in the inbound
      message any of the following may hold
         1. The sender of the inbound message will know that it will
            receive no SOAP response message over the connection used to
            send the inbound message (this is always the case over a
            fire-and-forget transport).
         2. The sender of the inbound message will expect a SOAP
            response message over the same connection.
         3. The sender of the inbound message may or may not receive a
            SOAP response over the same connection, depending on the
            application logic of the receiver.
   4. In case 3.3, some sort of acknowledgment is needed if no SOAP
      response occurs, for example, an empty 2xx response in HTTP.
   5. Transport failures may occur anywhere, including an in-only MEP
      over a fire-and-forget transport.  If this is to be considered as
      a SOAP message, each subitem of 3 will need to be amended in a
      tedious but straightforward way.

The following table attempts to summarize how the various proposals
address these facts.  I believe the handling (5) is orthogonal to
everything else, so I've omitted it.  Please read "HTTP" as "HTTP or
similar request-response transport. Please take this as a sketch and
feel free to correct any errors or inadvertent misrepresentations.  In
particular, I don't feel qualified to speak for the "über-MEP" proposal,
though I've taken my best guess:

*Proposal*
	*1 (HTTP req-rep)*
	*2 (Fire and Forget)*
	*3 (dynamically variable number of SOAP messages)*
	*4 (ack needed)*
Define request-response /or/ one-way, per transport ("DH1")
	HTTP  interaction  is  /always/ SOAP request-response MEP 	Always
one-way SOAP MEP
	One SOAP MEP per transport-level exchange
	Ack is a special SOAP message
One-way everywhere, request-response where supported. ("DH2")
	HTTP interaction is SOAP request-response MEP if response message
contains SOAP, one-way otherwise
	Always one-way SOAP MEP
	One one-way MEP per WSDL message, unless transport is request-response
and SOAP response was sent.
	Ack is transport-level, presence indicates one-way MEP
SOAP-level in-optional-out
	HTTP interaction is always in-optional-out, with "out" occurring if
SOAP response is sent.
	Always in-optional-out SOAP MEP without "out"
	One MEP per WSDL MEP, "out" present if transport is request-response
and a SOAP response was sent
	Ack is transport-level, presence indicates no "out"
Transport-level in-optional-out ("über-MEP")
	(?) HTTP interaction  is in-optional-out with "out" always present. 
"out" may or may not be SOAP.
	Always in-optional-out without "out"
	(?) "out" message may be absent or may not be SOAP
	(?) Ack is a distinguished "out" message.
Received on Wednesday, 14 December 2005 17:15:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:20 GMT