Asynch TF TBDs and options

Here's my list of what I think we need to decide.  Is this roughly
right?  What things have I missed, and what options are there?  As well,
any *short* suggestions for pros/cons are appreciated.

 

The Async TF, WSDL WG, and other works have highlighted a number of
outages in current standardization efforts to enable the async scenarios
described in [1].  Herein is a set of possibilities and some personal
recommendations.  One recommendation in Dec 2004 was a new one-way SOAP
MEP and one-way SOAP Binding.  

 

To a great deal, these options are specese for WSDL and any additional
specifications.  The things that are specified in WSDL and are on the
wire are identical.

 

1. Bindings

At least one new SOAP HTTP Binding is required.  The current SOAP HTTP
Binding requires that a SOAP response be carried in the HTTP Response,
from either the soap request-response mep or the soap-response mep.
Point #2 will describe the mep outages, but support for MEPs must be
described in any bindings discussion.

 

Options:

a. One new SOAP HTTP Binding for multiple SOAP meps.  This binding has a
"property" that is set for which MEP is in play.  Note the current SOAP
HTTP Binding has a "mep" property that is set by the web-method.

  a.1 Covers any new SOAP MEPs. 

  a.2 Covers all existing and new MEPs.

b. One new SOAP HTTP Binding for each new SOAP MEP.  

c. An option that Umit started discussing but I don't have the minutes
on.

 

Discussion

Is there a need for a WSDL author or SOAP stack to differentiate between
something like: 1) one-way mep + one-way binding or 2) one-way mep +
in-optional-response binding?   

 

2. MEPs

At least one new SOAP MEP is required.  Currently, one-way wsdl mep is
not describable.

 

Options:

a. One new SOAP MEP that is optional-out.  

  a.1. The mep has a "property" that can be set for whether out is
disallowed, allowed, or required.

     a.1.1 In-optional-out

     a.1.2 Optional-in-optional-out.  Let's not go into the issue of
property for setting cardinality of in right now...

  a.2. The mep does not have a property for the cardinality of the out.

b. Two new SOAP MEPs: in-only and in-optional-?

  b.1 in-optional-fault

  b.2 in-optional-out

 

Discussion.

Option a requires less "spec"ese for the meps.  The WSDL must set the
"property".  For example, in-only that maps to a soap in-optional-out
means the WSDL spec must "set" the out property to disallow response.  

 

Option b.2 facilitates WSDL 2.0 robust-in-only and in-optional-out.

 

3. WSDL 2.0 without WS-Addressing

WSDL 2.0 without WS-Addressing cannot describe the "protocol switch"
scenario or the "In-out one-way protocol" scenario.  

 

Options:

a. WSDL 2.0 can describe Protocol Switch

b. WSDL 2.0 can describe In-out one-way protocol scenario.

 

Cheers,

Dave

 

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

[2]
http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/0159.ht
ml