- From: Umit Yalcinalp <umit.yalcinalp@oracle.com>
- Date: Mon, 26 Jan 2004 13:31:02 -0800
- To: WS Description List <www-ws-desc@w3.org>
- Message-ID: <40158716.2050308@oracle.com>
Dear Members of the WG, Please find the attached proposal to add compositors to the WSDL specification. We would like to present the proposal and discuss the specifics at the f2f meeting. There is already a slot for discussing Features and Properties on Thursday morning's agenda and we hereby request our proposal to be included for discussion at that time. Thanks. --umit (on behalf of Oracle, Sonic, Sun and TIBCO) -- Umit Yalcinalp Consulting Member of Technical Staff ORACLE Phone: +1 650 607 6154 Email: umit.yalcinalp@oracle.com
Proposal for adding Compositors to WSDL 2.0
Roberto Chinnici, Sun Microsystems
Glen Daniels, Sonic Software
Anish Karmarkar, Oracle Corporation
Amelia Lewis, TIBCO Software
Umit Yalcinalp, Oracle Corporation
I. Introduction
It is necessary for Web services to advertise their capabilities in
the description of the services. This allows clients (or other Web
services) to obtain information about specific capabilities such as
transaction, reliability, security, of a specific Web service and
"invoke" it. Given that the description of the service is available in
a WSDL document, such capability assertions should be in the same
document and there should be a standard extensible framework for
tagging Web services with capability assertions.
WSDL 2.0 [1] provides such a framework through "Features and
Properties". This proposal enhances the Feature component available in
WSDL 2.0 to fully address the needs of a Web services to advertise its
capabilities, specifically composibility of features and properties.
This proposal provides the following enhancements in WSDL 2.0 where
features and/or properties are allowed to occur.
* defines compositors for combining features and properties to
express capabilities
* allows a feature to be composed of multiple "sub-features" and
properties
This enhacement would allow, for example, a Web service description to
advertise the fact that clients invoking the service must authenticate
itself using X.509 token, or kerberos token or username token.
II. Proposed additions to WSDL components that contain Features and Properties
II.A Compositors
This proposal introduces a new type of component called a Compositor.
Compositors are children elements of components that may contain
features and/or properties, such as interface, interface operation,
binding and binding operation components. A compositor specifies the
semantics for combining its children elements. These children elements
can be additional compositors, features, properties, extensions or
soap modules (only in binding and bindingoperation components).
A compositor component is expressed with the following pseudo-syntax
<compositor uri="...">
<documentation />?
[feature/> | <property/> | <compositor/> |
<wsoap:module/> |
<extensibility-element/>]+
</compositor>
Similar to all the components in WSDL, compositors are extensible.
The uri attribute of the compositor indicates its semantics. This
proposal describes 4 different compositors (URIs) and their semantics
below. It is possible to provide additional compositors by using
other URIs.
1. all: this compositor specifies that all the children elements must
be used. This compositor is identified by using the URI:
http://www.w3.org/wsdl20/all
2. choice: this compositor specifies that exactly one of the possibly
many children elements must be used. This compositor is identified by
using the URI: http://www.w3.org/wsdl20/choice
3. one-or-more: this compositor specifies that at least one of the
possibly many children elements must be used. This compositor is
identified by using the URI: http://www.w3.org/wsdl20/one-or-more
4. zero-or-more: this compositor specifies that one or more of the children
children elements may, but not required to be, used. This
compositor is identified by using the
URI: http://www.w3.org/wsdl20/zero-or-more
Examples for each compositor are provided in Section III below.
Note: The URIs specified in this proposal are placeholders.
Note 2: A soap module (wsoap:module) may only occur as a descendent of
a binding or a binding operation component.
II.B Proposed Changes to existing WSDL Components that may contain
Features and Properties
A WSDL component that currently is allowed to contain a feature or a
property is proposed to contain a compositor instead. These components
are interface, interface operation, binding and binding operation
components. The proposed change is illustrated using the interface
component using the pseudo-syntax below:
<definitions>
<interface
name="xs:NCName"
extends="list of xs:QName"?
styleDefault="xs:anyURI"? >
<documentation />?
[ <operation /> | <compositor /> ]*
</interface>
</definitions>
The compositors semantics describe how the features and properties are
composed for the enclosing component. The compositors' semantics
determine whether the composed elements are required or optional.
II.C Proposed Changes to the Feature Component
The current feature syntactic structure is modified to include
compositors as follows:
<feature
uri="xs:QName">
<documentation />?
[<compositor/> |
<extensibility-element/>]*
</feature>
Note 3: Since compositors determine whether an enclosed feature or
property is required or supported, the feature component, the property
component and wsoap:module components no longer have the required attribute
with this proposal.
III. Compositor Examples:
III.1 Example for the "all" compositor:
<binding>
<compositor uri="...">
<feature uri="http://example.com/security/non-repudiation">
<compositor uri="http://www.w3.org/wsdl20/all">
<feature uri="http://example.com/security/dsig"/>
<feature uri="http://example.com/security/non-repudiation/country/us">
<feature uri="http://example.com/security/non-repudiation/receipt-ack">
</compositor>
</feature>
<feature uri="..."/>
<feature uri="..."/>
</compositor>
<binding>
In the example above, the feature identified by URI
"http://example.com/security/non-repudiation" is a feature that
specifies that the inteface/binding to which this feature is attached
supports non-repudiation. This feature consists of three other
features, all of which are required because of the semantics of the
'all' compositor that composes the three features. The feature
identified by the URI "http://example.com/security/dsig" specifies
that every message sent and received by the inteface/binding must be
digitally signed. The feature identified by URI
"http://example.com/security/non-repudiation/country/us" specifies
that the legal ramifications of non-repudiation are as defined by the
the United States laws. The feature identified by the URI
"http://example.com/security/non-repudiation/receipt-ack" specifies
that the receipt of every non-ack message must be acknowledged by an
ack message.
III.2 Example for the "choice" compositor:
<binding name="example2.1">
<operation .../>
<operation .../>
<compositor uri="http://www.w3.org/wsdl20/choice">
<feature uri="http://example.com/authentication/username-token"/>
<feature uri="http://example.com/authentication/X.509-token"/>
</compositor>
</interface>
In the example above, the binding "example2.1" utilizes the "choice"
compositor that compose the two features. The feature identified by
the URI "http://example.com/authentication/username-token" specifies
that a username should be used for authentication as per the OASIS WSS
Username Token profile. The feature identified by the URI
"http://example.com/authentication/X.509-token" specifies that a X.509
certificate should be used for authentication as per the OASIS WSS
X.509 Certificate token profile. Per definition of the compositor, the
binding allows a choice between one of these features for
authentication and requires that one method of authentication must be
used.
Note that it is also possible to group these two features under a
single feature per our proposal as illustrated below.
<binding name="example2.2">
<operation .../>
<operation .../>
<compositor uri="http://www.w3.org/wsdl20/all">
<feature uri=""http://example.com/authentication">
<compositor uri=""http://www.w3.org/wsdl20/choice">
<feature uri="http://example.com/authentication/username-token"/>
<feature uri="http://example.com/authentication/X.509-token"/>
</compositor>
</feature>
<feature ..../>
<feature ..../>
</compositor>
</interface>
A feature identified by URI "http://example.com/authentication" is a
feature that provides a choice between two features identified by the
URIs "http://example.com/authentication/username-token" and
"http://example.com/authentication/X.509-token". This feature is among
several features that are required by the binding component per the
semantics of all compositor.
III.3 Example for the "one-or-more" compositor:
<binding>
....
<compositor uri="...">
<feature uri="http://example.com/reliability">
<compositor uri="http://www.w3.org/wsdl20/one-or-more">
<property uri="http://example.com/reliability/guaranteed-delivery">
<value>true</value>
</property>
<property uri="http://example.com/reliability/message-ordering">
<value>total-ordering</value>
</property>
<property uri="http://example.com/reliability/duplicate-removal>
<value>true</value>
</property>
</compositor>
</feature>
</compositor>
</binding>
In the example above, the feature identified by URI
http://example.com/reliability defines a reliable messaging protocol
and uses several properties that define quality of service that may be
provided by the feature. This example illustrates the usage of some of
these QoS for reliable messaging, such as delivery of messages in the
order received, removal of duplicate messages and guaranteeing that
messages are always delivered and how they may be utilized by using
the feature.
In this example, the feature component where specified in WSDL
(i.e. binding) uses at least one of the three QoS provided
by the feature by utilizing three different properties. The semantics
of the compositor illustrates that at least one of the properties must
be used that to indicate at least one of the QoS for reliable
messaging must be present.
III.4 Example for the "zero-or-more" compositor:
<interface name="example4">
<operation .../>
<operation .../>
<compositor uri="http://www.w3.org/wsdl20/zero-or-more">
<feature uri="http://example.com/ack">
<property uri="http://example.com/ack/QoS/within-24-hours">
<value>true</value>
</property>
</feature>
<feature uri=..../>
</compositor>
</interface>
In the example above, the interface "example4" contains a list of
supported but not required features. Among these features, the feature
identified by URI http://example.com/ack indicates that the client
will be acknowledged for the receipt of the message. This feature uses
one property, http://example.com/ack/QoS/within-24-hours. The
property http://example.com/ack/QoS/within-24-hours indicates that an
acknowledgement would be sent within 24 hours when the property value
is true. If the property is used, it indicates that
acknowledgement within 24 hours will be provided by the feature per
the semantics of zero-or-more compositor.
III.5 Nested Compositor Example
<interface name="example5">
<operation ..../>
<operation ..../>
<compositor uri="http://www.w3.org/wsdl20/all">
<feature uri="urn:f1"/>
<feature uri="urn:f2"/>
<compositor uri="http://www.w3.org/wsdl20/zero-or-more">
<feature uri="urn:f3"/>
<feature uri="urn:f3"/>
</compositor>
</compositor>
</interface>
This example illustrates that there are 4 different features that the
interface named "example5" supports. Features f1 and f2 are required
features, on the other hand, features f3 and f4 are supported, but not
required.
References:
[1] Web Services Description Language (WSDL) Version 2.0 Part 1: Core
Language, http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html
Received on Monday, 26 January 2004 16:31:30 UTC