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