[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrm] Proposal to resolve REL-49
Anish:
that looks clean, not overloaded, and I believe can be introduced
as naturally as any previous annotation mechanism.
See inline comments tagged <JD> in attached doc.
- I think the proposal needs be more explicit on how
to express "required-to-use" features vs. ""supported" features.
I gave it a try in my comments.
- these annotations map clearly to the notions of RM Agreement and RM Capability,
of which they are a concrete representation.
I think it is the proof that WS-Reliability is open to externally defined
ways to express WS policies, and proposes the right abstract notions to help this.
Jacques
-----Original Message-----
From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
Sent: Monday, February 23, 2004 6:30 PM
To: wsrm@lists.oasis-open.org
Subject: [wsrm] 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
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".
<JD> all these map straightforwardly to the "RM Agreement" items in 1.8.2.
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".
<JD> these reply patterns map to different values of the ReplyPattern "RM Agreement" item in 1.8.2.
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
<JD> this feature composition below actually maps directly to
the "RM Capability" notion, of which it is a concrete representation.
There is something I do not see that was in previous annotations
discussed with Sunil: specifying whether the WS actually "requires" the client
to use the feature, or simply "supports" the feature.
So i the example below, should the client use "all" three RM features,
or does the "all" mean that it can use any of them?
I assume it means the former, because the "one-or-more"
composer means you can use any these at your discretion (but at least one).
Let me know if I got these right:
- I guess we can use a "zero-or-more" composer to mean that the composed
features are all supported but optional for client.
- to say that a feature below is NOT supported, would require a "false" value
under an "all" composer (e.g. for message-ordering).
- to say that you must use either poll or callback but NOT response reply,
would require:
<compositor "all">
<compositor "one-or-more">
<..callback-reply-pattern..>true<>
<..poll-reply-pattern..>true<>
</compositor>
<..response-reply-pattern..>false<>
</compositor>
</JD>
<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
<JD> This doc below can be seen as a representation of the RM Agreement.
(with the difference here that you allow for more than 1 reply patterns)
</JD>
<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]