[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] Rel49
+1 -Anish -- Tom Rutt wrote: > 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. >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]