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

Here is a concrete proposal to resolve issue lc132.  This text would
replace sections 4.1 and 4.3, add a new subsection and perhaps renumber
the existing subsections in section 4.


4.1 Destination


The value of the [destination] message addressing property for a message
sent to an endpoint typically matches the value of the {address}
property of the endpoint component (WSDL 2.0) or the address value (if
any) provided by the relevant port extension (WSDL 1.1). For a SOAP 1.1
port described using WSDL 1.1, the value is provided by the location
attribute of the soap11:address extension element.  For an endpoint or
port extended as described in [4.x Extending WSDL Endpoints with an
EPR], the value is provided by the wsa:To element.

Additional runtime information could override the value of the
[destination] message addressing property for messages sent to an
endpoint, e.g. a runtime exchange might result in a redirection to a
different EPR. Note that WS-Addressing does not define any normative
mechanism for such redirection.

 


4.3 Reference Parameters


When a wsa:EndpointReference element is present in a wsdl20:endpoint or
a wsdl11:port element, the value of the [reference parameters] message
addressing property for a message sent to an endpoint MUST include the
contents of the wsa:ReferenceParameters element, if one exists within
that EPR.

 


4.x Extending WSDL Endpoints with an EPR


The wsa:EndpointReference element (see Web Services Addressing 1.0 -
Core[WS-Addressing-Core
<http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl.htm
l?content-type=text/html;%20charset=utf-8#WSADDR-CORE#WSADDR-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.

 


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
<http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl.htm
l?content-type=text/html;%20charset=utf-8#mapvaluesinwsdl#mapvaluesinwsd
l> 
    4.1 Extending WSDL Endpoints with an EPR

    4.2 Destination
<http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl.htm
l?content-type=text/html;%20charset=utf-8#destinwsdl#destinwsdl> 
    4.3 Reference Parameters
<http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl.htm
l?content-type=text/html;%20charset=utf-8#refpinwsdl#refpinwsdl> 

    4.4 Action
<http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl.htm
l?content-type=text/html;%20charset=utf-8#actioninwsdl#actioninwsdl> 
    

________________________________

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.

 

1.	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. 
2.	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. 
3.	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. 
4.	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. 
5.	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/
<http://www.w3.org/Submission/wsdl11soap12/> 

 

 

 [  Jonathan Marsh  ][  jmarsh@microsoft.com
<mailto:jmarsh@microsoft.com>   ][  http://spaces.msn.com/auburnmarshes
<http://spaces.msn.com/auburnmarshes>   ]