Robust-Request MEP and One-way + optional additional connection SOAP HTTP Binding

I offer a Robust-Request MEP and a SOAP HTTP One-way + Optional
Additional Connection binding.  The names are of course fungible.

 

There are 4 scenarios described in [1] that are completely solved.  

 

1. One-way WSDL MEP and HTTP

2. Robust In-only WSDL MEP and HTTP

3. In optional-out WSDL MEP and HTTP

4. Request-Response WSDL MEP and 2 HTTP connections.

 

There are 4 scenarios that are partially solved, they require additional
bindings.

 

1. One-way WSDL MEP and non-HTTP

2. Robust In-only WSDL MEP and non-HTTP

3. In optional-out WSDL MEP and non-HTTP

4. Request-Response WSDL MEP and 1 HTTP Connection for the Request and a
non-HTTP connection for the response.

 

I believe that Robust in-only is sufficient for all these cases.   Going
through the 3 possible meps:

 

If true one-way is selected

- Works fine for one-way underlying protocols.

- WSDL Robust In-only is lossy with HTTP because it doesn't allow a SOAP
fault to come back.  

 

If Robust In-only is selected

- one-way protocol binding must "throw away" any faults.  

- Works fine for HTTP.  

 

If In optional-out is selected

- one-way protocol binding must "throw away" any response.  

- HTTP Binding is less descriptive because the binding cannot tell a
sender that no response is expected. 

- This mep can be approximated by assuming the request-response mep and
then changing the mep to Robust in-only if no response is generated.

 

Proposed herein is the Robust Request MEP.

 

An HTTP One-way + Optional Additional Connection binding can cover a
variety of use cases, and is proposed herein.  The binding takes as
parameters an MEP, a message, an optional response protocol, an optional
response address, and an optional response message.  When the MEP is
robust in-only then the binding sends the message and waits for a fault.
When request-response MEP, then send the message and then call this
binding but with robust in-only MEP and the specified binding.

 

The algorithm is:

If (MEP==Robust in-only) then

   Message is transmitted using HTTP

   Optional Fault is transmitted

If (MEP==Request-Response) then

    Request Message is transmitted using HTTP

    If No response address specified then

       Set Fault to no response address, exit

    MEP is set to Robust in-only

    If response binding is empty then

       set response binding to HTTP One-way + Optional Additional
Connection binding

    Response Message is transmitted by specified binding

 

There are a few design points worth noting.  Firstly, the state machine
for the receiving node when responding remains as sending+receiving.
The receiving node could commence the use of the second binding at any
time after it has started receiving the request message.  This
parallelism is difficult to model in single threaded state machines.  It
is approximated by the use of the second binding for the response, with
no constraints placed upon timing of the start or finish of the 2nd
binding.  Secondly, this binding uses a second binding with Robust
in-only mep for the response part of the request-response mep.  The SOAP
binding framework does not specify any scoping rules for such a nesting
of bindings, and particularly for the properties or features used.
However, it is not precluded so this binding assumes that nesting is
possible.   Thirdly, this binding adds properties that are not specified
in the binding framework or in any of the used meps.  The binding
framework does not appear to preclude extending the binding framework in
this way.  

 

Cheers,

Dave

 

[1] http://www.pacificspirit.com/Authoring/async/async-scenarios.html

 

    

 

 

 

<PRE>--------------------------------------------------------------------------------

Join CEO Alfred Chuang and CTO Mark Carges on June 15 for a unique online 
event, giving you the first look at a new category of enterprise software 
built specifically for Service-Oriented Architecture (SOA).

Register Now.  It's Free!

http://www.bea.com/events/june15
</PRE>