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


The RM- agreement text for the mesage expiry and group expiry client 
configuration parameters should be used.  It already explains it as a 
duration.

thus, I propose that in the two subsections for messageExpiry time and 
group Expiry time, in the ws-reliabiliy portion of your proposal:

change:
"

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. ]]
"

To
"They type of this property is xs:duration.

Note: The expiry time is calculated at the time a message is sent, 
by adding this duration to the time the message is sent.
"


Anish Karmarkar wrote:

> 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>
>  
>
>  
>
>------------------------------------------------------------------------
>
>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





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