RE: Asynch TF TBDs and options

 

> -----Original Message-----
> From: public-ws-async-tf-request@w3.org 
> [mailto:public-ws-async-tf-request@w3.org] On Behalf Of Marc Hadley
> Sent: Friday, May 20, 2005 1:49 PM
> To: David Orchard
> Cc: public-ws-async-tf@w3.org
> Subject: 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.

Umit shares the same opinion Marc does. :-)

What I was advocating was that we don't necessarily need a new binding,
but an extension to the binding which tweaks the current requirement
that the SOAP message be carried in the HTTP rules. 


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

+1. 

> >
> >
> > 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 ?

+1.  I am more inclined to see (b). In both cases, you need a "marker"
to indicate what option you have, whether a property or via a URI that
designates which MEP you use. Perhaps it is a bottom up approach, but
once you solve b, you can always have (a) as the next step. This is
because you will always need a URI to designate a SOAP MEP (necessary
condition). For option b it is sufficient, for (a) it is not.  



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

I gather you mean SOAP/HTTP in SOAP/SMTP out? 

There is always option c. WSDL does not describe a Protocol Switch. 

To be more accurate, the modeling of Protocol switch may be modeled on
top of basic WSDL interactions, higher level extensions, etc. 

> >
> >
> > Cheers,
> >
> > Dave
> >

--umit

> >
> >
> > [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 21:37:12 UTC