[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Proposal to resolve REL-49
All, I am a new "prospective member" of WSRM. I have been an "observer" of this TC almost since its inception. I would like to put forward a proposal to resolve issue REL-49 [1]. The proposal consists of two parts: 1) FnPwsdl11-version2.txt -- this is a backport of the WSDL 2.0 Features and Property framework [2] to WSDL 1.1. This provides a generic extensible framework for annotating a WSDL document with features and properties. 2) ws-reliability-fnp.txt -- this contains definition of ws-reliability specific features and properties. These two parts together, I believe address issue REL-49 [1]. Editorial suggestion: If the TC thinks that this proposal makes sense, I would like to suggest that this proposal (or whatever form the TC ends up accepting, if it does at all) be placed in two separate appendices. Comments? Thanks and regards. -Anish Karmarkar Oracle Corp. -- [1] http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/5304/wsrm-issues-2004-02-04.html#xREL-49 [2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0153.html
Proposal for Adding Compositors, Features and Properties to WS-Reliability
--------------------------------------------------------------------
[[ Note: This proposal is the WSDL 1.1 analogue of the proposal [1] that is
currently under discussion in WSD WG. Also note that WSDL 2.0 component
model defines features and properties, whereas WSDL 1.1 does not. ]]
I. Introduction
It is necessary for WS-Reliability to advertise its capabilities in
the description of services. This allows clients (or other Web
services) to obtain information about specific capabilities such as
guaranteed delivery, duplicate elimination, message ordering, and various
reply patterns of a specific Web service and "invoke" it. Given that the
description of the service is available in a WSDL document, such capability
assertions need be in the same document. Therefore there is a need for a
standard extensible framework for tagging Web services with capability
assertions.
This proposal uses the WSDL 1.1 extensibility points to define an extensible
framework consisting of features, properties and compositors to address
the needs of a reliable Web services to advertise its capabilities, and
composability of those capabilities.
This proposal defines the following extensibility elements and the semantics
associated with them that forms an extensible framework:
* feature - abstract functionality associated with WSDL elements.
* property - value or value constraint associated with WSDL elements.
* compositor - specify how features and properties are combined.
This extensible framework 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.
I.A Notational Convention
This specification uses the following namespace prefixes:
Prefix Namespace
------ ---------
xs "http://www.w3.org/2001/XMLSchema";
wsdl11 "http://schemas.xmlsoap.org/wsdl/";
fnp "http://www.ws-standards.org/fnp/";
The choice of any namespace prefix is arbitrary and not semantically
significant.
I.B Conformance
Implementations of WS-Reliability are expected, though not required, to
understand the WSDL extensibility points defined in this proposal.
Understanding of these extensibility points promotes interoperability. When a
WSDL document contains these extensibility points, it is through these
extensibility points that a service advertises its supported and required
features. Therefore it is RECOMMENDED that implementations recognize,
understand and support these extensibility points.
It is also possible for services to advertise features through other channels
(such as UDDI) in addition to these extensibility point. Mandating that every
conformant implementation recognize, understand and support these
extensibility points is considered to be too high a bar for conformant
implementations. Therefore, it is not required (though recommended) that every
conformant implementation support these extensibility point.
II. Proposed Extensibility Elements
II.A Compositor
This proposal introduces a new extensibility element called a compositor.
The compositor semantics describe how features and properties are
composed for the enclosing component (or WSDL 1.1 element). The compositor's
semantics determine whether the composed elements are required or optional.
A compositor element can occur as a child element of wsdl11:portType,
wsdl11:operation (which may itself be a child of wsdl11:portType or
wsdl11:binding), and wsdl11:binding. The compositor element utilizes the
extensibility defined by WSDL 1.1. A compositor element specifies the
semantics for combining its children elements. These children elements can be
additional compositor, features, properties, or extensibility element(s).
A compositor element is expressed by the following pseudo-syntax:
<fnp:compositor uri="...">
[fnp:feature/> | <fnp:property/> | <fnp:compositor/> |
<extensibility-element/>]+
</fnp:compositor>
The uri attribute of the compositor specifies its semantics. This
proposal describes four different compositors (URIs) and their semantics
below. It is possible to provide additional compositors by using
other URIs. The ability to define additional compositors and the existence of
extensibility points (represented by "<extensibility-element>") make the
framework extensible.
1. all: this compositor specifies that all the children elements MUST
be used. This compositor is identified by using the URI:
"http://www.ws-standards.org/fnp/compositors/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.ws-standards.org/fnp/compositors/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.ws-standards.org/fnp/compositors/one-or-more";
4. zero-or-more: this compositor specifies that one or more of the children
elements MAY be used (but it is not required). This
compositor is identified by using the URI:
"http://www.ws-standards.org/fnp/compositors/zero-or-more";
Examples for each compositor are provided in Section III below.
II.B Feature
A feature describes an abstract piece of functionality associated with a WSDL
element. This proposal places no restriction on what a feature may represent.
Typical expected examples of features include security, reliability and other
QoS aspects of Web services. A feature can occur only as a child of a
compositor. Whether a feature is required or not is defined by the enclosing
compositor(s). A feature is identified by a URI. Recognizing the URI of a
feature is considered to be equivalent to understanding the feature identified
by that URI.
A feature element is expressed by the following pseudo-syntax:
<fnp:feature uri="...">
[<fnp:compositor/> | <extensibility-element/>]*
</fnp:feature>
II.C Property
A property is identified by a QName. A property can consists of either a value
or a constraint on the set of values. Typically properties are associated with
with a feature (but are not required to) and are descriped in a feature
specification. The QName identifier of a property uniquely identifies the
property. Recognizing the property QName identifier is considered to be
equivalent to understanding the semantics associated with that property. The
property QName identifier typically points a global XML Schema element
declaration. A property specification typically specifies the schema that
contains this global element declaration. A constraint on the set of values
that a property can have is specified by a QName that identifies a XML Schema
type.
<fnp:property name="xs:QName">
[<fnp:value>xs:anyType</fnp:value> |
<fnp:constraint>xs:QName</fnp:constraint>]
[<extensibility-element/>]*
</fnp:property>
III. Compositor Examples:
III.A Example for the "all" Compositor:
<wsdl11:binding name="example-1">
<fnp:compositor uri="...">
<fnp:feature uri="http://example.com/security/non-repudiation";>
<fnp:compositor uri="http://www.ws-standards.org/fnp/compositors/all";>
<fnp:feature uri="http://example.com/security/dsig"/>
<fnp:feature uri="http://example.com/security/non-repudiation/country/us"/>
<fnp:feature uri="http://example.com/security/non-repudiation/receipt-ack"/>
</fnp:compositor>
</fnp:feature>
<fnp:feature uri="..."/>
<fnp:feature uri="..."/>
</fnp:compositor>
...
<wsdl11:binding>
In the example above, the feature identified by URI
"http://example.com/security/non-repudiation"; is a feature that
specifies that the 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 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.B Example for the "choice" compositor:
<wsdl11:binding name="example2">
<wsdl11:operation ...>
<fnp:compositor uri="http://www.ws-standards.org/fnp/compositors/choice";>
<fnp:feature uri="http://example.com/authentication/username-token"/>
<fnp:feature uri="http://example.com/authentication/X.509-token"/>
</fnp:compositor>
...
</wsdl11:operation>
...
</wsdl11:binding>
In the example above, the binding "example-2" 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 nest these two features under a
single feature as follows:
<wsdl11:binding name="example3">
<wsdl11:operation ...>
<fnp:compositor uri="http://www.ws-standards.org/fnp/compositors/all";>
<fnp:feature uri=""http://example.com/authentication";>
<fnp:compositor uri=""http://www.ws-standards.org/fnp/compositors/choice";>
<fnp:feature uri="http://example.com/authentication/username-token"/>
<fnp:feature uri="http://example.com/authentication/X.509-token"/>
</fnp:compositor>
</fnp:feature>
</fnp:compositor>
...
</wsdl11:operation>
...
</wsdl11:binding>
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
required by the binding component per the semantics of "all" compositor.
III.C Example for the "one-or-more" compositor:
<wsdl11:binding name="example4"
xmlns:ex="http://example.com/reliability";>
<fnp:compositor uri="...">
<fnp:feature uri="http://example.com/reliability";>
<fnp:compositor uri="http://www.ws-standards.org/fnp/compositors/one-or-more";>
<fnp:property name="ex:guaranteed-delivery">
<fnp:value>true</fnp:value>
</fnp:property>
<fnp:property name="ex:message-ordering">
<fnp:value>total-ordering</fnp:value>
</fnp:property>
<fnp:property name="ex:duplicate-removal>
<fnp:value>true</fnp:value>
</fnp:property>
</fnp:compositor>
</fnp:feature>
</fnp:compositor>
....
</wsdl11: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 binding (where the feature is specified) 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.D Example for the "zero-or-more" compositor:
<wsdl:portType name="example5"
xmlns:ex="http://example.com/ack/QoS";>
<wsdl11:operation ...>
<fnp:compositor uri="http://www.ws-standards.org/fnp/compositors/zero-or-more";>
<fnp:feature uri="http://example.com/ack";>
<fnp:compositor uri="http://www.ws-standards.org/fnp/compositors/zero-or-more";>
<fnp:property name="ex:within-24-hours">
<fnp:value>true</fnp:value>
</fnp:property>
</fnp:compositor>
</fnp:feature>
<fnp:feature uri=..../>
</fnp:compositor>
...
</wsdl11:operation>
...
</wsdl11:portType>
In the example above, the portType "example5" 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
acknowledgment would be sent within 24 hours when the property value
is true. If the property is used, it indicates that
acknowledgment within 24 hours will be provided by the feature per
the semantics of zero-or-more compositor.
III.E Nested Compositor Example
<wsdl11:portType name="example6">
<wsdl11:operation ....>
<fnp:compositor uri="http://www.ws-standards.org/fnp/compositors/all";>
<fnp:feature uri="urn:f1"/>
<fnp:feature uri="urn:f2"/>
<fnp:compositor uri="http://www.ws-standards.org/fnp/compositors/zero-or-more";>
<fnp:feature uri="urn:f3"/>
<fnp:feature uri="urn:f3"/>
</fnp:compositor>
</fnp:feature>
</fnp:compositor>
</wsdl11:operation>
...
</wsdl11:portType>
This example illustrates that there are 4 different features that the
portType named "example6" supports. features f1 and f2 are required
features, on the other hand, features f3 and f4 are supported, but not
required.
References:
[1] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0153.html
WS-Reliability Specific Features and Properties Proposal
--------------------------------------------------------
I. Introduction
This proposal defines WS-Reliability specific features and properties that can
be specified in a WSDL document using the features and properties extensible
framework. These features and properties when specified in a WSDL document
specify the reliability capabilities and assertions associated with specific
WSDL constructs.
I.A Notational Convention
This specification uses the following namespace prefixes:
Prefix Namespace
------ ---------
xs "http://www.w3.org/2001/XMLSchema";
wsdl11 "http://schemas.xmlsoap.org/wsdl/";
fnp "http://www.ws-standards.org/fnp/";
wsrm "http://www.oasis-open.org/committees/wsrm/schema/1.1/fnp/";
The choice of any namespace prefix is arbitrary and not semantically
significant.
II. WS-Reliability Feature
The WS-Reliability feature is identified by the URI
"http://www.oasis-open.org/committees/wsrm/schema/1.1/fnp/";
This feature URI identifies the WS-Reliability specification. Understanding
this URI implies understanding the WS-Reliability specification.
III. WS-Reliability Properties
This section identifies properties for the WS-Reliability specification.
Typically these properties would be scoped within the feature identified by the
URI "http://www.oasis-open.org/committees/wsrm/schema/1.1/fnp/";
III.A. Guaranteed Delivery Property
This property is identified by the QName "wsrm:guaranteed-delivery" and
corresponds to the semantics specified by the WS-Reliability guaranteed
delivery semantics. The type of this property is "xs:boolean".
III.B. Duplicate Elimination Property
This property is identified by the QName "wsrm:duplicate-elimination" and
corresponds to the semantics specified by the WS-Reliability duplicate
elimination semantics. The type of this property is "xs:boolean".
III.C. Message Ordering Property
This property is identified by the QName "wsrm:message-ordering" and
corresponds to the semantics specified by the WS-Reliability message
ordering semantics. The type of this property is "xs:boolean".
III.D. Response Pattern Property
This property is identified by the QName "wsrm:response-reply-pattern" and
corresponds to the semantics specified by the WS-Reliability response-reply
pattern semantics. The type of this property is "xs:boolean".
III.E. Callback Pattern Property
This property is identified by the QName "wsrm:callback-pattern" and
corresponds to the semantics specified by the WS-Reliability callback
pattern semantics. The type of this property is "xs:boolean".
III.F. Poll Pattern Property
This property is identified by the QName "wsrm:poll-pattern" and
corresponds to the semantics specified by the WS-Reliability poll
pattern semantics. The type of this property is "xs:boolean".
IV. Client Side Properties
In addition to the properties defined in section III, there are
WS-Reliability properties that are specified only at the client side (and
therefore do not occur in the WSDL document) deployment descriptors.
This section identifies such properties. These properties MUST NOT be specified
in the WSDL document. How the properties are specified and/or represented does
not affect interoperability as these properties are client-side only
properties. They are defined here for convenience only.
IV.A. Group Expiry Time
This property is identified by the QName "wsrm:group-expiry-time" and
corresponds to the semantics specified by the WS-Reliability group expiration
time. The type of this property is xs:dateTime.
[[ Note: In most client-side deployments it is expected that
wsrm:group-expiry-time would be defined as something like "Now + duration",
rather than an absolute date/time (which would be translated into an absolute
date/time for every group). From that perspective it might be worthwhile
to define this property as xs:duration OR keep it untyped. ]]
IV.B. Group Maximum Idle Duration
This property is identified by the QName "wsrm:group-max-idle-duration" and
corresponds to the semantics specified by the WS-Reliability group maximum idle
duration. The type of this property is xs:duration.
IV.C. Message Expiration Time
This property is identified by the QName "wsrm:msg-expiry-time" and
corresponds to the semantics specified by the WS-Reliability message expiration
time. The type of this property is xs:dateTime.
[[ Note: In most client-side deployments it is expected that
wsrm:msg-expiry-time would be defined as something like "Now + duration",
rather than an absolute date/time (which would be translated into an absolute
date/time for every message). From that perspective it might be worthwhile
to define this property as xs:duration OR keep it untyped. ]]
IV.D. Retry Maximum Time
This property is identified by the QName "wsrm:retry-max-times" and
corresponds to the semantics specified by the WS-Reliability maximum retry
times. The type of this property is xs:int.
IV.E. Retry Time Interval
This property is identified by the QName "wsrm:retry-time-interval" and
corresponds to the semantics specified by the WS-Reliability retry time
interval. The type of this property is xs:duration.
IV.F. ReplyTo URI
This property is identified by the QName "wsrm:reply-to" and
corresponds to the semantics specified by the WS-Reliability reply-to.
The type of this property is xs:anyURI.
V. Schema
<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
xmlns:wsrm="http://www.oasis-open.org/committees/wsrm/schema/1.1/fnp/";
targetNamespace="http://www.oasis-open.org/committees/wsrm/schema/1.1/fnp/";
elementFormDefault="qualified" >
<!-- properties to be used in WSDL -->
<xs:element name="guaranteed-delivery" type="xs:boolean"/>
<xs:element name="duplicate-elimination" type="xs:boolean"/>
<xs:element name="message-ordering" type="xs:boolean"/>
<xs:element name="response-reply-pattern" type="xs:boolean"/>
<xs:element name="callback-reply-pattern" type="xs:boolean"/>
<xs:element name="poll-reply-pattern" type="xs:boolean"/>
<!-- properties to be used on the client side -->
<xs:element name="group-expiry-time" type="xs:dateTime"/>
<xs:element name="group-max-idle-duration" type="xs:duration"/>
<xs:element name="msg-expiry-time" type="xs:dateTime"/>
<xs:element name="retry-max-times" type="xs:int"/>
<xs:element name="retry-time-interval" type="xs:duration"/>
<xs:element name="reply-to" type="xs:anyURI"/>
</xs:schema>
VI. Examples
VI.A Example 1
<wsdl11:portType name="myReliablePort">
<fnp:compositor uri="http://www.ws-standards.org/fnp/compositor/all";>
<fnp:feature uri="http://www.oasis-open.org/committees/wsrm/schema/1.1/fnp/";
<fnp:compositor uri="http://www.ws-standards.org/fnp/compositor/all";>
<fnp:property name="wsrm:duplicate-elimination">
<fnp:value>true</fnp:value>
</fnp:property>
<fnp:property name="wsrm:message-ordering">
<fnp:value>true</fnp:value>
</fnp:property>
<fnp:property name="wsrm:guaranteed-delivery">
<fnp:value>true</fnp:value>
</fnp:property>
<fnp:compositor uri="http://www.ws-standards.org/fnp/compositors/one-or-more";>
<fnp:property name="wsrm:response-reply-pattern">
<value>true</value>
</fnp:property>
<fnp:property name="wsrm:callback-reply-pattern">
<value>true</value>
</fnp:property>
<fnp:property name="wsrm:poll-reply-pattern">
<value>true</value>
</fnp:property>
</fnp:compositor>
</fnp:compositor>
</fnp:feature>
</fnp:compositor>
<wsdl11:operation>
...
</wsdl11:operation>
</wsdl11:portType>
VI.B Example 2: A simple client side DD
<client-config>
<fnp:compositor uri="http://www.ws-standards.org/fnp/compositors/all";>
<fnp:feature uri="http://www.oasis-open.org/committees/wsrm/schema/1.1/fnp/";>
<fnp:compositor uri="http://www.ws-standards.org/fnp/compositors/all";>
<fnp:property name="wsrm:guaranteed-delivery">
<fnp:value>true</fnp:value>
</fnp:property>
<fnp:compositor uri="http://www.ws-standards.org/fnp/compositors/one-or-more";>
<fnp:property name="wsrm:response-reply-pattern">
<fnp:value>true</fnp:value>
</fnp:property>
<fnp:compositor uri="http://www.ws-standards.org/fnp/compositors/all";>
<fnp:property name="wsrm:reply-to">
<value>http://example.com/listener/</value>
</fnp:property>
<fnp:property name="wsrm:callback-reply-pattern">
<fnp:value>true</fnp:value>
</fnp:property>
</fnp:compositor>
<fnp:property name="wsrm:poll-reply-pattern">
<fnp:value>true</fnp:value>
</fnp:property>
</fnp:compositor>
<fnp:property name="wsrm:msg-expiry-time">
<fnp:value>...</fnp:value>
</fnp:property>
<fnp:property name="wsrm:retry-time-interval">
<fnp:value>...</fnp:value>
</fnp:property>
<fnp:property name="wsrm:retry-max-tries">
<value>5</value>
</fnp:property>
</fnp:compositor>
</fnp:feature>
</fnp:compositor>
</client-config>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]