[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrm] Proposal to resolve REL-49
At 08:56 AM 3/2/2004, chris.hipson@bt.com wrote: >Anish wrote :- > >I would note that if we do not specify where these properties/features > >can occur, how they are represented, and how they are processed, then >we > >do not have an interoperable mechanism to specify ws-reliability > >capabilities/assertions. > >My understanding is that these capabilities are largely icing on the >cake as the protocol has been designed to function without them? > > >Without such a mechanism how does one resolve issue REL-49? > >How does the Oracle implementation interoperate with the SAP >implementation? > > >IMHO, the TC can either choose to say that they do not care about > >interoperability, OR bite the bullet and decide that interop is > >important and specify a way to 'annotate' the WSDL documentation -- I, > >obviously support the latter. > >Unfortunately the proposed annotation scheme isn't yet a definite >standard. > My understanding is that while WSDL 2 Features and Properties >seem fairly certain to appear their exact form and status is yet to be >determined. The proposal is to use a WSDL 1.1 extensibility point. There is no dependency on anything the WSDL 2.0 group may or may not do, now or in the future. jeff >Cheers Chris Hipson > >-----Original Message----- >From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com] >Sent: 02 March 2004 15:13 >To: Goodner, Marc Andrue >Cc: Jacques Durand; 'tom@coastin.com'; wsrm@lists.oasis-open.org >Subject: Re: [wsrm] Proposal to resolve REL-49 > >I would note that if we do not specify where these properties/features >can occur, how they are represented, and how they are processed, then we > >do not have an interoperable mechanism to specify ws-reliability >capabilities/assertions. > >Without such a mechanism how does one resolve issue REL-49? >How does the Oracle implementation interoperate with the SAP >implementation? > >IMHO, the TC can either choose to say that they do not care about >interoperability, OR bite the bullet and decide that interop is >important and specify a way to 'annotate' the WSDL documentation -- I, >obviously support the latter. > >-Anish >-- > >Goodner, Marc Andrue wrote: > > My principal objection is to the composition mechanism. My suspicion >is > > that any fully defined WSDL annotation will take us right back in the > > direction of a general mechanism. Defining the properties without a > > container doesn't help much now, it helps in the future once that > > container has been defined in a generic way elsewhere. Those same > > properties could be used now within the wsdl:documentation which of > > course does not provide the same expressive power but is all we can > > really hope to achieve without a general mechanism for their use. - >Marc g > > > > >------------------------------------------------------------------------ > > *From:* Jacques Durand [mailto:JDurand@us.fujitsu.com] > > *Sent:* Sunday, Feb 29, 2004 19:46 PM > > *To:* Goodner, Marc Andrue; Jacques Durand; 'tom@coastin.com'; >Anish > > Karmarkar; wsrm@lists.oasis-open.org > > *Subject:* 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:marc.andrue.goodner@sap.com] > > *Sent:* Friday, February 27, 2004 4:08 PM > > *To:* Jacques Durand; 'tom@coastin.com'; Anish Karmarkar; > > wsrm@lists.oasis-open.org > > *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:JDurand@us.fujitsu.com] > > *Sent:* Thursday, Feb 26, 2004 23:19 PM > > *To:* 'tom@coastin.com'; wsrm@lists.oasis-open.org > > *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: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/fn >p/" > > > > > 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_workgrou >p.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_workgrou >p.php. > > > >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_workgrou >p.php. > > > >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. Jeff Mischkinsky jeff.mischkinsky@oracle.com Consulting Member Technical Staff +1(650)506-1975 Director, Web Services Standards 500 Oracle Parkway M/S 4OP9 Oracle Corporation Redwood Shores, CA 94065
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]