OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrm] Rel49


Attached is the modified version of my original proposal.

The change from the original proposal is:

1) Replaced "http://www.ws-standards.org/fnp/";
with "http://www.oasis-open.org/committees/wsrm/schema/1.1/fnp/";

2) Replaced "http://www.oasis-open.org/committees/wsrm/schema/1.1/fnp/";
with "http://www.oasis-open.org/committees/wsrm/schema/1.1/feature/rel/";

As before, 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.
2) ws-reliability-fnp.txt -- this contains definition of ws-reliability 
specific features and properties.

I hope this addresses the concern regarding having a non-wsrm namespace.

If you prefer to have different namespaces than what is proposed, please 
  let me know.

Thanks!

-Anish
--

iwasa wrote:

> Anish and all,
> 
> Since we have short time remaining before
> WS-I F2F meeting, we must close Rel49 by the telecon 
> next week with concrete proposal with text to be 
> incorporated in the spec.
> 
> *And* if we can not agree the resolution by that time,
> I would propose we do not include anything
> in the spec for Rel49 and close the issue with no action.
> 
> I do not agree to spend additional one more week when
> we can't close the issue by the next telecon.
> 
> So I would propose Anish to send out proposal
> ASAP (by the end of this week at latest, I would suggest) 
> to discuss and agree with the proposal before the telecon, 
> if you really need your proposal accepted. Otherwise there
> would be chance of running out of time.
> 
> I hope we resolve issue49 before the next telecon.
> 
> Thanks,
> 
> Iwasa
> 

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.oasis-open.org/committees/wsrm/schema/1.1/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.oasis-open.org/committees/wsrm/schema/1.1/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.oasis-open.org/committees/wsrm/schema/1.1/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.oasis-open.org/committees/wsrm/schema/1.1/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.oasis-open.org/committees/wsrm/schema/1.1/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.oasis-open.org/committees/wsrm/schema/1.1/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.oasis-open.org/committees/wsrm/schema/1.1/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.oasis-open.org/committees/wsrm/schema/1.1/fnp/compositors/all";>
      <fnp:feature uri=""http://example.com/authentication";>
        <fnp:compositor uri=""http://www.oasis-open.org/committees/wsrm/schema/1.1/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.oasis-open.org/committees/wsrm/schema/1.1/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.oasis-open.org/committees/wsrm/schema/1.1/fnp/compositors/zero-or-more";>
      <fnp:feature uri="http://example.com/ack";>
        <fnp:compositor uri="http://www.oasis-open.org/committees/wsrm/schema/1.1/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.oasis-open.org/committees/wsrm/schema/1.1/fnp/compositors/all";>
      <fnp:feature uri="urn:f1"/>
      <fnp:feature uri="urn:f2"/>
        <fnp:compositor uri="http://www.oasis-open.org/committees/wsrm/schema/1.1/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.oasis-open.org/committees/wsrm/schema/1.1/fnp/";
  wsrm            "http://www.oasis-open.org/committees/wsrm/schema/1.1/feature/rel/";

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/feature/rel/";

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/feature/rel/";

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/feature/rel/";
    targetNamespace="http://www.oasis-open.org/committees/wsrm/schema/1.1/feature/rel/";
    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.oasis-open.org/committees/wsrm/schema/1.1/fnp/compositor/all";>
    <fnp:feature uri="http://www.oasis-open.org/committees/wsrm/schema/1.1/feature/rel/";
      <fnp:compositor uri="http://www.oasis-open.org/committees/wsrm/schema/1.1/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.oasis-open.org/committees/wsrm/schema/1.1/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.oasis-open.org/committees/schema/1.1/fnp/compositors/all";>
    <fnp:feature uri="http://www.oasis-open.org/committees/wsrm/schema/1.1/feature/rel/";>
      <fnp:compositor uri="http://www.oasis-open.org/committees/schema/1.1/fnp/compositors/all";>
        <fnp:property name="wsrm:guaranteed-delivery">
          <fnp:value>true</fnp:value>
        </fnp:property>
        <fnp:compositor uri="http://www.oasis-open.org/committees/schema/1.1/fnp/compositors/one-or-more";>
          <fnp:property name="wsrm:response-reply-pattern">
            <fnp:value>true</fnp:value>
          </fnp:property>
          <fnp:compositor uri="http://www.oasis-open.org/committees/schema/1.1/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]