Re: Asynch TF TBDs and options

On May 20, 2005, at 3:20 PM, David Orchard wrote:
> 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.
Saying that a *new* SOAP HTTP binding is required makes it sound like  
such a big deal. All that's really needed is a tweak to the existing  
binding to remove the requirement that a SOAP message be carried in  
the HTTP response. If we can make this clear so that people don't  
perceive it as a huge piece of work I think we'll stand a better  
chance of getting good traction.

>
>
> 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 a makes the mep more complex but there's only one of them.  
Option b makes the meps simpler but there's two of them. Its really  
just a question of where you put the complexity - right ?

Marc.
>
>
> 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.html
>
>
>
>
>
>
>
>

---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.

Received on Friday, 20 May 2005 20:49:25 UTC