Next in thread →
Next in month →
RE: [wsrm] Proposal to resolve REL-49
Title: RE: [wsrm] Proposal to resolve REL-49
Marc:
Is it
your position that you are opposed to any fully defined form of WSDL annotation
at this time?
Or
only opposed to a composition mechanism that you consider too generic and beyond
scope?
(as
you point out, defining the properties without even providing a container
element in WSDL
would
not help much.)
Jacques
-----Original Message-----
From: Goodner, Marc Andrue
[mailto:]
Sent: Friday, February 27, 2004
4:08 PM
To: Jacques Durand; ''; Anish Karmarkar;
Subject: RE: [wsrm] Proposal to resolve
REL-49
I have no issue with defining WS-Reliability specific
properties as described in the second part of Anish's proposal and I would
also support making them a little more expressive as per Tom and Jacques'
suggestions below. However, I can not support the first part of the proposal
to define Compositors, Features and Properties either as part of
WS-Reliability or through this TC in any form. I believe that functionality is
too generic to be defined as part of our work and is clearly out of our
scope.
I think we can all agree that the
capability specified in that proposal is something that is missing
from WSDL 1.1 and needs to be addressed. Likewise I believe we can all agree
that it will be addressed, whether that be in WSDL 2.0 or in some other way.
From what we know, or think we do, of these things, having the specific
WS-Reliability properties defined by this TC would allow better use of our
protocol not only with Compositors, Features and Properties as we understand
it today, but potentially with any other similar
mechanism.
So I believe defining these properties would be
worthwhile and facilitate the adoption of WS-Reliability in the future. While
it may not seem like it makes as much sense without a known defined mechanism
to use them today, providing them is forward thinking and does no
harm. But to define a specific mechanism to use them, in my
opinion, is going to far. The result of following that path could quite
possibly result in a contentious OASIS membership vote or even
threaten the adoption of WS-Reliability.
Regards,
Marc Goodner
SAP
From: Jacques Durand
[mailto:]
Sent: Thursday, Feb 26, 2004
23:19 PM
To: '';
Subject: RE: [wsrm] Proposal to resolve
REL-49
This is somehow what we had in the initial annotation
schema.
That would work on the WS end-point
(capabilities) but would
be confusing on the client
side if we want to use the same annotation syntax.
If I were to improve on Anish proposal, I'd manage to
keep parameter names and values as close as in the original
RM agreement,
so to not mingle the names, and not
make boolean values that were not originally.
For example, instead of expressing:
"client must use either Poll or Callback replyPattern"
as:
<comp="one-or-more">
<prop
name="callback-reply-pattern">true</prop>
<prop name="poll-reply-pattern">true</prop>
</comp>
I would use:
<comp="one-or-more">
<prop
name="reply-pattern">callback</prop>
<prop name="reply-pattern">poll</prop>
</comp>
Jacques
-----Original Message-----
From: Tom
Rutt [mailto:]
Sent: Thursday, February 26, 2004 3:46 PM
To:
Subject: Re:
[wsrm] Proposal to resolve REL-49
I have a question.
If the types of the ws reliability paramters which are now
"boolean"
were changed to an enum:
supported
notSupported
Requires.
That would allow more expressiveness in the compositor
framework.
Granted, the use of required with zero or more compositor
does not make
much sense, but with 1orMore or All
the differentiation
between supported and required
might make a difference in the semantics
of the
compositor usage.
What do you think?
Tom Rutt
Anish Karmarkar wrote:
> 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>
>
>
>
>
>------------------------------------------------------------------------
>
>To unsubscribe from this
mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
>
--
----------------------------------------------------
Tom Rutt
email: ;
Tel: +1 732 801
5744 Fax: +1 732 774
5133
To unsubscribe from this mailing list (and be removed from
the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
Next in thread →
Next in month →