W3C home > Mailing lists > Public > public-ws-addressing@w3.org > February 2005

RE: detailed proposal for issues i024 and i026

From: <paul.downey@bt.com>
Date: Mon, 7 Feb 2005 20:43:04 -0000
Message-ID: <2B7789AAED12954AAD214AEAC13ACCEF2709DFBF@i2km02-ukbr.domain1.systemhost.net>
To: <Steve.Vinoski@iona.com>, <public-ws-addressing@w3.org>
i personally don't like the idea of sending WSDL information in an EPR,
it seems to me that a WSDL is good way to describe messages being
exchanged on the wire, but tying the messages themselves to a particular
description is limiting.
Given i may elect to describe an individual message exchange in any
one of a number of WSDLs each with their own abstract interface 
name, sentences like "it MUST match *the* WSDL 2.0 interface name ...." 
trouble me somewhat.

	-----Original Message----- 
	From: public-ws-addressing-request@w3.org on behalf of Vinoski, Stephen 
	Sent: Fri 04/02/2005 19:07 
	To: public-ws-addressing@w3.org 
	Subject: detailed proposal for issues i024 and i026

	Below find a detailed proposal for resolving issues i024 and i026. Unlike our
	previous draft proposal [1], this one details the changes this proposal
	would make to the Core and WSDL binding specs, as requested by the WG in the
	Monday 31 Jan 2005 teleconference.
	[1] <http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jan/0202.html>
	Paco Curbera (IBM)
	Greg Truty IBM)
	Rebecca Bergersen (IONA)
	Steve Vinoski (IONA)
	Anish Karmarkar (Oracle)
	Umit Yalcinalp (SAP)
	Marc Hadley (Sun)
	We (IBM, IONA, Oracle, SAP, Sun) propose the following as a resolution
	to issues i024 (metadata) and i026 (multiple ports). The
	representation of multiple ports may be considered metadata, and hence
	can be resolved within the metadata solution described below.
	Our proposed solution is to add a metadata element to the EPR, and
	move all existing EPR metadata elements into it:
	   <wsa:ReferenceParameters>...</wsa:ReferenceParameters> ?
	   <wsa:Metadata>...</wsa:Metadata> ?
	The EPR metadata element is intended to allow creators of EPRs to
	include as much or as little metadata within each EPR as they deem
	necessary. It allows for the inclusion of metadata directly ("by
	value"), as well as for the inclusion of metadata indirectly ("by
	reference"), or any combination thereof.
	We propose that semantics and usage for metadata contained within the
	EPR metadata element are specified by the relevant specification that
	defines that particular metadata. The reason for this is that we
	believe it allows for easy extensibility of the EPR with respect to
	policies and other metadata. We propose moving the definitions of the
	semantics and usage for any WSDL metadata that can appear within the
	EPR metadata element to the WSDL binding document [1]. Similarly, any
	future WS-Policy metadata intended for use within the EPR metadata
	element would be defined in a WS-Addressing WS-Policy binding
	The current draft WS-Addressing specification [2] already defines
	several metadata elements within the EPR. Specifically, in section
	2.1, the selected interface, service endpoint, and policies elements
	each represent optional EPR metadata. As indicated by the previous
	paragraph, we propose moving all of these elements into the EPR
	metadata element.
	Metadata defined within the EPR metadata element follows the
	precedence definition defined in the resolution to issue i014 [3].
	[1] <http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl.html>
	[2] <http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-core.html>
	[3] <http://www.w3.org/2002/ws/addr/wd-issues/#i014>
	Changes to the WS-Addressing Core Working Draft
	Section 2.1: remove the [selected interface], [service endpoint], and
	[policies] abstract properties and their descriptions. Add the
	following abstract property and description:
	[metadata] : xs:any (0..1)
	A reference may contain metadata that describes the behavior,
	policies, requirements, and capabilities of an endpoint. Metadata may
	be included in a reference to facilitate easier processing by a
	consuming application, or because the metadata was dynamically
	generated. However, such metadata is not authoritative and may be
	stale or incoherent with the metadata associated with the endpoint at
	the time the interaction occurs.
	Section 2.2: change example 2-1 as follows:
	  <wsa:ReferenceParameters>...</wsa:ReferenceParameters> ?
	  <wsa:Metadata>...</wsa:Metadata> ?
	>From the list following example 2-1, remove items
	/wsa:EndpointReference/wsa:Policies/{any} and their
	descriptions. Replace these items and descriptions with the following:
	This OPTIONAL element contains the elements that convey the [metadata]
	of the reference.
	Each child element of Metadata represents an individual [metadatum].
	This is an extensibility mechanism to allow additional attributes to
	be specified. Some examples in this specification show use of this
	extensibility point to include a wsdlLocation[WSDL 2.0] attribute to
	provide a hint for the location of a WSDL description of the WSDL
	metadata specified within the [metadata] property.
	Change the description for item /wsa:EndpointReference/@{any} as
	This is an extensibility mechanism to allow additional attributes to
	be specified.
	Change Example 2-2 and the text just before it as follows:
	The following shows an example endpoint reference. As indicated in its
	[metadata], this element references the [selected interface]
	"fabrikam:Inventory" at the endpoint URI
	"http://example.com/www.fabrikam/acct". Note the use of the WSDL[WSDL
	2.0] wsdlLocation attribute.

	Changes to the WSDL Binding Working Draft
	Section 2: replace the final paragraph of the beginning of this
	section with the following:
	Endpoint references complement and do not replace WSDL services.  We
	expect solutions built on WSDL to continue to utilize service
	definitions. The endpoint references may link to services in WSDL, and
	may directly cache information from WSDL definitions. Endpoint
	references also support additional scenarios in which the WSDL
	information is not known by a party processing a message. These
	scenarios may include dynamic messaging or limited capability message
	Section 2.1: replace this entire section with the following:
	2.1 Information Model for Endpoint References
	The WSDL binding of Web Services Addressing introduces the following
	additional abstract properties for use within the [metadata] element
	of the endpoint reference:
	[selected interface] : QName (0..1)
	A QName identifying a description of the sequences of messages that a
	service sends and/or receives. This corresponds to a WSDL 2.0
	interface and/or a WSDL 1.1 port type. If this property appears in EPR
	[metadata] together with a [service] property, it MUST match the WSDL
	2.0 interface name or one of the WSDL 1.1 port names specified in the
	[service] property.
	[service endpoint] : (QName, NCName (0..1)) (0..1)
	A QName, NCName pair that provide a reference to a full description of
	a set of service endpoints. The QName identifies the set of endpoints
	at which a particular Web service is deployed, the NCName identifies
	one endpoint in particular. The set of endpoints is represented by a
	service in WSDL 2.0 and WSDL 1.1. A particular endpoint is represented
	by an endpoint in WSDL 2.0 and a port in WSDL 1.1. If this property
	appears in EPR [metadata] together with a [service] property, it MUST
	match the WSDL service name specified in the [service] property.
	[service] : (WSDL 1.1 or 2.0 service definition) (0..1)
	A service definition as specified by either the WSDL 1.1 or WSDL 2.0
	specification. If a [service] property appears in EPR [metadata], then
	a [service endpoint] property MUST be specified, because the service
	QName in the [service endpoint] specifies the targetNamespace for the
	[service] property name attribute. If the [service] property specifies
	multiple endpoints, then the port NCName MUST be specified in the
	[service endpoint]. When a [service] property contains multiple
	endpoints, all endpoints supporting the same interface/portType as the
	one indicated by the [service endpoint] property are considered
	alternative access channels (address plus binding) to reach the same
	Example 2-1. An EPR containing WSDL 2.0 metadata.

	      <wsa:ServiceName EndpointName="ep1">
	      <wsdl20:service name="InventoryService"
	         <wsdl20:endpoint name="ep1" binding="abc:soap-http-binding"
	         <wsdl20:endpoint name="ep2" binding="abc:iiop"
	         <wsdl20:endpoint name="ep3"
	Example 2-2. An EPR containing WSDL 1.1 metadata.
	      <wsa:ServiceName EndpointName="ep1">
	      <wsdl11:service name="InventoryService">
	         <wsdl11:port name="ep1" binding="abc:soap-http-binding">
	            <soap:address location="http://example.com/fabrikam/acct"/>
	         <wsdl11:port name="ep2" binding="abc:iiop">
	            <iiop:address location="..."/>

Received on Monday, 7 February 2005 20:42:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:08 UTC