Re: Asynchronous Binding action item.

I can't tell on a quick examination, so I'll ask: is this expected to work
for any MEP other than in-out?

Amy!
On Tue, 11 May 2004 18:23:43 -0700
David Orchard <dorchard@bea.com> wrote:

> 
> In order to do an Asynchronous binding, that is binding an abstractly
> synchronous operation to 2 synchronous operations in the binding, it
> means that most of the binding operation constructs that are expected on
> the input side must also be available for the output.  The way that a
> wsoap:operation extends the binding operation must be available for the
> output as well as the input.   Further, the service must have a way of
> specifying what the address of the "callback" is.
> 
> The current model is:
> <binding>
> <operation ref="xs:QName" >
>       <documentation />?
> 
>       <wsoap:operation mep="xs:anyURI"?
>                        webMethod="xs:string"? 
>                        action="xs:anyURI"? 
>                        mediaType="xs:string"?/>?
> 
>       <input messageLabel="xs:NCName"? >
>         <documentation />?
>         <wsoap:header element="xs:QName" 
>                       mustUnderstand="xs:boolean"?
>                       role="xs:anyURI"?
>                       relay="xs:boolean"? 
>                       reinsert="xs:boolean"? />*
>       </input>*
> 
>       <output messageLabel="xs:NCName"? >
>         <documentation />?
>         <wsoap:header ... />*
>       </output>*
> </operation>
> 
> This causes us problems because we want to retain the
> operation/input|output model.  The part of wsoap:operation that is
> useful to both input and output is the mep.  Therefore, I propose that
> the wsoap:operation split into 2 with the mep retained as an operation
> extension and the rest of the attributes be moved inside input and
> optionally output.  
> 
> <operation ref="xs:QName" >
>       <documentation />?
> 
>       <wsoap:mep="xs:anyURI"/>?
>       <input messageLabel="xs:NCName"? >
>          <documentation />?
>          <wsoap:operation webMethod="xs:string"? 
>                           action="xs:anyURI"? 
>                           mediaType="xs:string"?/>?
>          <wsoap:header element="xs:QName" 
>                       mustUnderstand="xs:boolean"?
>                       role="xs:anyURI"?
>                       relay="xs:boolean"? 
>                       reinsert="xs:boolean"? />*
>       </input>*
> 
>       <output messageLabel="xs:NCName"? >
>         <documentation />?
>         <wsoap:operation webMethod="xs:string"? 
>                           action="xs:anyURI"? 
>                           mediaType="xs:string"?/>?
>         <wsoap:header ... />*
>       </output>*
> </operation>
> 
> The endpoint is split into two for the service.  An endpoint MAY have an
> asynch address element.  In this case, the referenced binding must have
> an operation with output with an operation extension element (ie
> operation/output/wsoap:operation).  The asynchaddress may be an an
> "unknown" address which indicates that the address is dynamic.
> 
> <endpoint name="xs:NCName" binding="xs:QName" >
>       <documentation />?
>       <wsoap:address location="xs:anyURI" />
>       <wsoap:asynchaddress location="xs:anyURI" />
> <endpoint>
> 
> When a WSDL document is exchanged, the location of an endpoint may not
> be known to the WSDL publisher.   Some examples of this scenario are
> asynchronous message exchanges with callbacks and non-addressible
> software.  WSDL defines a URI for specifying these "unknown" locations
> 
> http://www.w3.org/2004/wsdl/part3/unknown
> 
> It is expected that messages that are sent to the unknown location will
> use some other mechanism, such as runtime soap headers, for exchanging
> the location.  
> 
> Cheers,
> Dave
> 


-- 
Amelia A. Lewis
Architect/Principal Engineer
TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Wednesday, 12 May 2004 10:50:33 UTC