Re: [lc132]: Proposal: Reference Parameters vs. complete EPRs

I'm generally in favor of this proposal but I have a question about  
one aspect of it, see below.

On Apr 17, 2006, at 1:06 PM, Jonathan Marsh wrote:
> 4.x Extending WSDL Endpoints with an EPR
> The wsa:EndpointReference element (see Web Services Addressing 1.0  
> - Core[WS-Addressing-Core]) MAY be used as an extension child  
> element of the wsdl20:endpoint or wsdl11:port elements. When  
> present, the value of the [destination] message addressing property  
> of the EPR MUST have the same value as the {address} property, if  
> any, of the endpoint component. For WSDL 1.1 the [destination]  
> message addressing property MUST have the same value as the address  
> supplied by the binding extension.  For example, in a SOAP 1.1 port  
> described using WSDL 1.1, the location attribute of the  
> soap11:address element must have the same value as the wsa:Address  
> element.

Its not clear in the above what the "When present" refers to: a  
wsa:EndpointReference element, or the [address] property (note that  
an EPR doesn't have a [destination] MAP, only messages have those) ?  
I note that [address] is mandatory in an EPR so I think I'd rephrase  
the above as follows:

"A wsdl20:endpoint or wsdl11:port element MAY be extended using a  
child wsa:EndpointReference element. When extended this way, the  
[address] property of the child EPR must match the {address} property  
of the endpoint component (WSDL 2.0) or the address value provided by  
the relevant port extension (WSDL 1.1). For example, in a SOAP 1.1  
port described using WSDL 1.1, the location attribute of the  
soap11:address element must have the same value as the wsa:Address  
element."

Does this capture the intent ?

Marc.

>
>
>
>
> 4.x.1 WSDL 2.0 Component Model Changes
> Use of WS-Addressing adds the following OPTIONAL properties to the  
> WSDL 2.0 component model:
>
> A property of the Endpoint component, named {endpoint reference}.  
> This property is of type wsa:EndpointReference, with a cardinality  
> of 1. The property has the value of the wsa:EndpointReference  
> element used as a child of wsdl20:endpoint, if any.  If no such  
> extension exists, this property is absent.
>
>
>
> Although there are other ways to do it, I would probably reorganize  
> and renumber Section 4 as follows:
>
>
>
> 4. Specifying Message Addressing Properties in WSDL
>     4.1 Extending WSDL Endpoints with an EPR
>
>     4.2 Destination
>     4.3 Reference Parameters
>
>     4.4 Action
>
>
> From: public-ws-addressing-tests-request@w3.org [mailto:public-ws- 
> addressing-tests-request@w3.org] On Behalf Of Jonathan Marsh
> Sent: Tuesday, April 11, 2006 4:43 PM
> To: public-ws-addressing-tests@w3.org
> Subject: Reference Parameters vs. complete EPRs
>
>
>
> Section 4.3 ReferenceParameters
>
> The current mechanism for embedding EPR information in a WSDL  
> endpoint/port misses an opportunity to provide some useful  
> benefits, which would be regained by embedding the whole EPR rather  
> than just the ReferenceParameters element.
>
>
>
> Address information can appear in WSDL in a variety of ways.  In  
> WSDL 1.1 it can appear in the wsoap11:element attribute, or in the  
> wsoap12:address element if the WSDL 1.1 Binding Extension for SOAP  
> 1.2 submission [1] (acknowledged by W3C yesterday) is used.  In  
> WSDL 2.0 it can appear in the wsdl:endpoint/@address attribute.   
> Allowing wsa:Address to extend the endpoint/port provides a  
> consistent way to serialize addresses regardless of the WSDL and  
> SOAP version in use.
> Deconstructing an EPR to serialize it into WSDL requires special  
> serialization code.  Instead of having a single codepath for  
> serializing an EPR, we need a WSDL-specific way to serialize just  
> the ReferenceParameters.
> Multiple serializations become increasingly painful as EPR  
> extensions are developed, which would each have to be serializable  
> in two flavors – EPR extensions, and endpoint/port extensions.
> Every EPR extension would also have to be defined both as an EPR  
> extension and as a WSDL extension, making the development of EPR  
> extensions more complex.
> We currently use 2004/08 EPRs as WSDL extensions without  
> deconstructing them, and we’d like a consistent model between the  
> submitted and standardized models.
>
>
> We therefore request that section 4.3 specify that a whole EPR can  
> be embedded in an endpoint/port.  If both an EPR and one of the  
> *:address mechanisms are present, the address values MUST match.
>
>
>
> [1] http://www.w3.org/Submission/wsdl11soap12/
>
>
>
>
>
>  [  Jonathan Marsh  ][  jmarsh@microsoft.com  ][  http:// 
> spaces.msn.com/auburnmarshes  ]
>
>
>
>

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

Received on Tuesday, 18 April 2006 15:35:25 UTC