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.