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] Proposal to resolve REL-49


Title: 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:tom@coastin.com]
Sent: Thursday, February 26, 2004 3:46 PM
To: wsrm@lists.oasis-open.org
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: tom@coastin.com; trutt@fsw.fujitsu.com
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.



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