[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrm] Proposal to resolve REL-49
Below, <mag/> -----Original Message----- From: Jeff Mischkinsky [mailto:jeff.mischkinsky@oracle.com] Sent: Tuesday, Mar 02, 2004 9:12 AM To: chris.hipson@bt.com; Anish.Karmarkar@oracle.com; Goodner, Marc Andrue Cc: JDurand@us.fujitsu.com; tom@coastin.com; wsrm@lists.oasis-open.org Subject: RE: [wsrm] Proposal to resolve REL-49 <snip/> > >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. <mag>Well, that then makes this a specific mechanism of our TC even though it I obviously generic. It seems pretty clear to me that our spec would then be referred to expressly for the purpose of utilizing the Compositors, Features and Properties which changes the responsibility picture for maintenance, errata and future versions fairly significantly. This is a lot of additional responsibility for a non normative requirement. To me this is the clearest indication that it does not belong here.</mag> 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]