RE: Issue 59 proposal

Hi Marc,

Perhaps the biggest difference is the one I've been talking about for a
while, which is specifying the relationship between wsdl meps and the
bindings.  In my proposal, I say specifically how a wsdl req-resp maps
to a protocol independent mep.  That way, I can write the
wsaw:UsingAddressing and async extension in a protocol independent
manner.  While 95% of the SOAP req-resp mep doesn't help us -
particularly the state machine, the soap mandatoriness and the mandatory
response - at least having a protocol independent mep is a good thing.

I believe that such a layering is critical and is the thing I'm prepared
to be strident about.  

QNames would work instead of URIs, though I guess I'm a URI bigot :-)
It's not a showstopper, as long as it's either qname or URI (qname AND
URI is the worst of all worlds).

I'm not particularly jazzed about lists of elements with qnames in them,
seems like a convoluted design to me.  Might be easier to have the
qnames as element names instead of element values.

But, I tell ya what, if you could live with an abstract MEP, I could
live with qnames and elements :-)

Dave



> -----Original Message-----
> From: Marc.Hadley@Sun.COM [mailto:Marc.Hadley@Sun.COM]
> Sent: Friday, November 04, 2005 2:45 PM
> To: David Orchard
> Cc: public-ws-addressing@w3.org
> Subject: Re: Issue 59 proposal
> 
> I think it may be insufficient to identify the response binding using
> the transport/protocol URI, bindings are potentially much more
> complex than that. In my proposal[1] I used a QName to identify an
> actual binding instance in the WSDL and I think that offers more
> capability.
> 
> As a personal preference I'm also not too jazzed with attributes that
> contain lists - that's why I chose a child element instead.
> 
> Other than the above our proposals seem pretty much in-line, did I
> miss something radically different ?
> 
> Marc.
> 
> [1] http://www.w3.org/mid/D1503191-88CA-4537-A20A-1F891F43606D@Sun.COM
> 
> On Nov 4, 2005, at 10:22 AM, David Orchard wrote:
> 
> > I propose a wsaw:UsingAddressing element with a wsaw:Async and
> > wsaw:ResponseBinding attributes that uses an abstract protocol (aka
> > uber) MEP to show the relationship between wsdl request-response
> > and protocol level request-response without mentioning a specific
> > protocol.  There are 9 examples including protocol switch and
> > reverse bindings, so everybody should be happy.3.1 UsingAddressing
> > Extension Element
> > WS-Addressing defines an empty global element,
> > wsaw:UsingAddressing, that may be used to indicate that an endpoint
> > conforms to the WS-Addressing specification. The wsdl:required
> > attribute MAY be used to indicate whether WS-Addressing Message
> > Addressing Properties are required in messages received from
> > service requesters.
> >
> > A wsaw:UsingAddressing element with a wsdl:required attribute whose
> > value is "true" indicates that messages exchanged with the endpoint
> > MUST contain WS-Addressing Message Addressing Properties. A
> > wsaw:UsingAddressing element with a wsdl:required attribute whose
> > value is "false" indicates that the endpoint will accept input
> > messages with or without WS-Addressing header blocks, and MAY
> > generate output messages containing WS-Addressing headers. If a
> > SOAP binding is used and WS-Addressing header blocks are not
> > present in an input message then WS-Addressing header blocks
> > encoded in the corresponding output message MUST NOT be required to
> > be understood using the SOAP mustUnderstand mechanism.
> >
> > The wsaw:UsingAddressing element SHOULD appear as a child of the
> > wsdl:binding element. Alternatively, the wsaw:UsingAddressing
> > element MAY instead be included as a child of the wsdl20:endpoint
> > (or wsdl11:port) when an endpoint intends to indicate compliance
> > with WS-Addressing for a specific endpoint only.
> >
> > The inclusion of the wsaw:UsingAddressing element indicates that
> > the applicable WS-Addressing specifications are supported within
> > the constraints of the WSDL binding being used. That is, uses of
> > the WS-Addressing specifications that may violate or are
> > inconsistent with the semantics of the endpoint's WSDL binding are
> > not supported unless explicitly stated by some other mechanism.
> >
> > Specifically, when included in a SOAP binding, the
> > wsaw:UsingAddressing marker identifies the use of Web Services
> > Addressing 1.0 bound to SOAP as defined by Web Services Addressing
> > 1.0 - SOAP Binding[WS-Addressing-SOAP].
> >
> > (Note to reader: Up to this point, this is exactly the same text
> > from the current editor's draft.  It does need a titch of updating
> > as it isn't an empty global element.
> >
> > 3.1.1 wsaw:Async attribute
> > WS-Addressing defines an attribute, wsaw:Async, that may be used in
> > conjunction with wsaw:UsingAddressing element.  This attribute MAY
> > be used only when wsaw:UsingAddressing element is present.
> >
> > The wsaw:Async attribute may have three distinct values, "full",
> > "never" and "always". If the wsaw:Async attribute is not present,
> > then a value of "full" is the default.
> >
> > *        The "full" value indicates that either one or two protocol
> > message exchange pattern (proposed in [1] request-optional-response
> > MEP or in [2] as SOAP-request MEP) instances is used to transmit
> > the request and response.  When wsaw:Async attribute has this
> > value, then the response message MAY be the response part (aka
> > http://www.w3.org/2004/12/ws-addr/mep/ResponseMessage or http://
> > www.w3.org/2003/05/soap/mep/InboundMessage) of a request-optional-
> > response or request-response MEP or the response message MAY be the
> > request part (aka http://www.w3.org/2004/12/ws-addr/mep/
> > RequestMessage or http://www.w3.org/2003/05/soap/mep/
> > OutboundMessage) of a separate request-optional response or request
> > MEP. When the value of the [reply endpoint] in the request message
> > contains the anonymous URI as the address, the response MUST be
> > sent as the response part of the request-optional-response MEP.
> > When the value of [reply endpoint] contains an address that is
> > different than the anonymous URI, the response MUST the request
> > part of a separate request-optional response MEP with a binding
> > using the destination address value specified by [reply endpoint].
> >
> > *        The "never" value indicates that a single protocol MEP is
> > in use.  When wsaw:Async attribute has this value, [reply endpoint]/
> > [fault endpoint] EPRs in the request MUST NOT contain an address
> > with a value different from the anonymous URI. If [reply endpoint]/
> > [fault endpoint] EPRs do not contain the anonymous address value,
> > then a predefined InvalidAddressingHeader fault defined in Section
> > 5.4.1.7 of defined by Web Services Addressing 1.0 - SOAP Binding[WS-
> > Addressing-SOAP] MUST be generated  (See Section 3 B for the
> > definition of this new fault).
> >
> > *        The "always" value of the wsaw:Async attribute indicates
> > that a separate request-optional-response MEP for sending response
> > messages. When wsaw:Async attribute has this value, [reply
> > endpoint]/[fault endpoint] EPR in the request MUST NOT contain an
> > address with a value that is the same as the anonymous URI.
> >
> > 3.1.2 wsaw:ResponseBinding attribute
> > WS-Addressing defines an attribute, wsaw:ResponseBinding, that may
> > be used in conjunction with wsaw:UsingAddressing element.  This
> > attribute MAY be used only when wsaw:UsingAddressing element is
> > present.
> >
> > The wsaw:ResponseBinding attribute is a list of URIs of bindings
> > that may be specified for any asynchronous response.  If the
> > wsaw:ResponseBinding is not present, and the wsaw:Async attribute
> > is not "never", then the default value is the value of the binding
> > within which the wsaw:UsingAddressing element appears.  It is an
> > error if the ResponseBinding contains a value and if the wsaw:Async
> > attribute is "never".
> >
> > A sender of a request message SHOULD use the ResponseBinding value
> > when creating [reply endpoint] values.
> >
> > 3.1.3 SOAP HTTP Binding extensions
> > The wsaw:UsingAddressing inside soap:binding elements extends the
> > SOAP/HTTP Bindings in a few specific ways.
> >
> > Case: WSDL in-out (or request-response) and SOAP 1.1 and non-
> > anonymous [reply endpoint] is specified.
> >
> > The first HTTP connection MUST have a status code of 202 and the
> > response message MUST contain an empty SOAP body.  The actual
> > response MUST be sent using a separate HTTP connection using the
> > address value of the response message specified by [reply endpoint].
> >
> > Case: WSDL in-out (or request-response) and SOAP 1.2 and non-
> > anonymous [reply endpoint] is specified.
> >
> > Each of the two request-optional-response MEPs be sent using a
> > separate instance of the @@TBD SOAP 1.2 one-way binding@@.
> >
> > 3.1.4 Examples
> >
> >
> > These examples are an update to the async scenarios listed in [3].
> > As described therein, the identifier for the mythical one-way
> > protocol is "http://www.openuri.org/mythical-oneway/soap/"
> >
> >
> >
> > Example 3-1. Indicating Sync or Async in WS-Addressing using
> > wsaw:UsingAddressing in WSDL 2.0
> >
> > <binding name="ServiceBinding"
> >
> >     interface="s0:ServiceInterface"
> >
> >     type="http://www.w3.org/2005/08/wsdl/soap12"
> >
> >     wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
> >
> >   <wsaw:UsingAddressing wsdl:required="true" />
> >
> >   <operation ref="s0:EchoString"
> >
> >       wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-
> > response" />
> >
> > </binding>
> >
> > Example 3-2. Indicating Sync or Async in WS-Addressing using
> > wsaw:UsingAddressing in WSDL 1.1
> >
> > <binding name="ServiceBinding" type="s0:ServicePortType">
> >
> >   <soap:binding style="document" transport="http://
> > schemas.xmlsoap.org/soap/http" />
> >
> >   <wsaw:UsingAddressing wsdl:required="true" />
> >
> >   <operation name="EchoString">
> >
> >     <soap:operation soapaction="EchoString" />
> >
> >     <input>
> >
> >       <soap:body use="literal" />
> >
> >     </input>
> >
> >     <output>
> >
> >       <soap:body use="literal" />
> >
> >     </output>
> >
> >   </operation>
> >
> > </binding>
> >
> > Example 3-3. Indicating Sync in WS-Addressing using
> > wsaw:UsingAddressing in WSDL 2.0
> >
> > <binding name="ServiceBinding"
> >
> >     interface="s0:ServiceInterface"
> >
> >     type="http://www.w3.org/2005/08/wsdl/soap12"
> >
> >     wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
> >
> >   <wsaw:UsingAddressing wsaw:Async="never" wsdl:required="true" />
> >
> >   <operation ref="s0:EchoString"
> >
> >       wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-
> > response" />
> >
> > </binding>
> >
> >
> >
> > Example 3-4. Indicating Async in WS-Addressing using
> > wsaw:UsingAddressing in WSDL 2.0
> >
> > <binding name="ServiceBinding"
> >
> >     interface="s0:ServiceInterface"
> >
> >     type="http://www.w3.org/2005/08/wsdl/soap12"
> >
> >     wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
> >
> >   <wsaw:UsingAddressing wsaw:Async="always" wsdl:required="true" />
> >
> >   <operation ref="s0:EchoString"
> >
> >       wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-
> > response" />
> >
> > </binding>
> >
> >
> >
> > Example 3-5. Indicating Async with Mythical Oneway Binding in WS-
> > Addressing using wsaw:UsingAddressing in WSDL 2.0
> >
> > <binding name="ServiceBinding"
> >
> >     interface="s0:ServiceInterface"
> >
> >     type="http://www.w3.org/2005/08/wsdl/soap12"
> >
> >     wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
> >
> >   <wsaw:UsingAddressing wsaw:Async="always" wsdl:required="true"
> >
> >       ResponseBinding="http://www.openuri.org/mythical-oneway/
> > soap/" />
> >
> >   <operation ref="s0:EchoString"
> >
> >       wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-
> > response" />
> >
> > </binding>
> >
> >
> >
> >
> >
> > Example 3-6. Indicating Async with HTTP or Mythical Binding in WS-
> > Addressing using wsaw:UsingAddressing in WSDL 2.0
> >
> > <binding name="ServiceBinding"
> >
> >     interface="s0:ServiceInterface"
> >
> >     type="http://www.w3.org/2005/08/wsdl/soap12"
> >
> >     wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
> >
> >   <wsaw:UsingAddressing wsaw:Async="always" wsdl:required="true"
> >
> >        ResponseBinding="http://www.w3.org/2003/05/soap/bindings/
> > HTTP http://www.openuri.org/mythical-oneway/soap/" />
> >
> >   <operation ref="s0:EchoString"
> >
> >       wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-
> > response" />
> >
> > </binding>
> >
> >
> >
> > Example 3-7. Indicating Sync or Async with HTTP or Mythical Binding
> > in WS-Addressing using wsaw:UsingAddressing in WSDL 2.0
> >
> > <binding name="ServiceBinding"
> >
> >     interface="s0:ServiceInterface"
> >
> >     type="http://www.w3.org/2005/08/wsdl/soap12"
> >
> >     wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
> >
> >   <wsaw:UsingAddressing wsaw:Async="full" wsdl:required="true"
> >
> >        ResponseBinding="http://www.w3.org/2003/05/soap/bindings/
> > HTTP http://www.openuri.org/mythical-oneway/soap/" />
> >
> >   <operation ref="s0:EchoString"
> >
> >       wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-
> > response" />
> >
> > </binding>
> >
> >
> >
> > Example 3-8. Indicating Async in Interface in WS-Addressing using
> > wsaw:UsingAddressing in WSDL 2.0
> >
> > <interface name="ServiceInterface">
> >
> >   <wsaw:UsingAddressing wsaw:Async="always" wsdl:required="true" />
> >
> >   <operation name="EchoString" pattern="http://www.w3.org/@@@@/@@/
> > wsdl/in-out">
> >
> >     <input element="s0:EchoStringMessageIn"/>
> >
> >     <output element="s0:EchoStringMessageOut"/>
> >
> >   </operation>
> >
> > </interface>
> >
> >
> >
> > The above is only a possibility.  It would require updating the
> > usingAddressing to say what it means if a child of interface, and
> > it would require changes to disallowResponseBindings.
> > Alternatively, the async attribute could be made an element for
> > inclusion as a child of interface.
> >
> >
> >
> > Example 3-9. Indicating PAOS Async in WS-Addressing using
> > wsaw:UsingAddressing in WSDL 2.0
> >
> > <binding name="ServiceBinding"
> >
> >     interface="s0:ServiceInterface"
> >
> >     type="http://www.w3.org/2005/08/wsdl/soap12"
> >
> >     wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP">
> >
> >   <wsaw:UsingAddressing wsaw:Async="always" wsdl:required="true" />
> >
> >   <paos:reverseBinding wsdl:required="true"/>
> >
> >   <operation ref="s0:EchoString"
> >
> >       wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-
> > response" />
> >
> > </binding>
> >
> >
> >
> > The paos:reverseBinding would have to say something akin to :
> >
> >
> >
> > "In the first protocol MEP, put the paos:Get value in the Action
> > MAP and generate a full paos Get request including other MAPs.  The
> > first protocol MEP response must contain the binding operation's
> > request.  The response may have a [reply endpoint].  The second
> > protocol MEP request must contain the binding operation's response
> > and be sent to any [reply endpoint]. "
> >
> >
> >
> > Cheers,
> >
> > Dave
> >
> >
> >
> > [1] http://lists.w3.org/Archives/Public/public-ws-addressing/
> > 2005Jul/att-0010/ws-addr-soapadjuncts-simplemeps_httpbinding.html
> >
> > [2] http://lists.w3.org/Archives/Public/public-ws-addressing/
> > 2004Dec/att-0159/WS-Addressing-SOAP-Adjuncts.html
> >
> > [3]
http://www.pacificspirit.com/Authoring/async/async-scenarios.html
> >
> >
> >
> >
> 
> ---
> Marc Hadley <marc.hadley at sun.com>
> Business Alliances, CTO Office, Sun Microsystems.
>

Received on Saturday, 5 November 2005 01:39:54 UTC