OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

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


Subject: Prelim minutes of WSRM teleconf 3/9/04


The prelim minutes are attached.

We voted to initiate a 6 Day CD ballot to close just before our next 
tuesday teleconference.  The ballot will be
started before 5:00 PM Eastern Time on March 10, 2004.

-- 
----------------------------------------------------
Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133


Title: Draft Agenda to WSRM TC Conference Call – May 06, 2003

Preliminary Minutes WSRM TC Conference Call – Mar 09, 2004

 

The meeting of the WSRM TC took place by teleconference 
Tuesday, March 09 2004, from 5:30 to 6:45 PM Eastern Standard Time
(UTC - 5)

0         Draft Agenda:

Draft Agenda to WSRM TC Conference Call

1 Roll Call

2 Minutes Discussion

2.1 Appointment of Minute Taker

2.2 Approval of previous meeting minutes –

3 Discussion of New Orleans Meeting and Conference papers

4 Discussions of Issues

5 Discussion of Editorial Comments

6 Discussion of Document Progression

Agenda was approved

1         Roll Call

Attendance:

First Name

Last Name

Email

Role

Company

Voting Level

Joseph

Chiusano

chiusano_joseph@bah.com

Member

Booz-Allen Hamilton

1

Jeff

Turpin

jturpin@cyclonecommerce.com

Member

Cyclone Commerce

1

Jacques

Durand

jdurand@us.fujitsu.com

Member

Fujitsu

1

Kazunori

Iwasa

kiwasa@jp.fujitsu.com

Secretary

Fujitsu

1

Tom

Rutt

tom@coastin.com

TC Chair

Fujitsu

1

Jishnu

Mukerji

jishnu@hp.com

Member

Hewlett-Packard

1

Robert

Freund

bob.freund@hitachisoftware.com

Member

Hitachi

1

Eisaku

Nishiyama

nishiy_e@itg.hitachi.co.jp

Member

Hitachi

1

Nobuyuki

Yamamoto

no_yama@bisd.hitachi.co.jp

Member

Hitachi

1

John

Fuller

jfuller@wernervas.com

Observer

Individual

 

Mark

Peel

mpeel@novell.com

Member

Novell

1

Anish

Karmarkar

Anish.Karmarkar@oracle.com

Prosp Member

Oracle

 

jeff

mischkinsky

jeff.mischkinsky@oracle.com

Member

Oracle

1

marc

goodner

marc.andrue.goodner@sap.com

Secretary

SAP

1

Doug

Bunting

doug.bunting@Sun.com

Secretary

Sun

1

Tony

Graham

Tony.Graham@Sun.com

Member

Sun

1

 

Meeting was quorate.

2         Minutes Discussion

2.1      Appointment of Minute Taker

Tom Rutt will take minutes.

 

Minutes will serve to record issue resolutions.

2.2      Approval of previous meeting minutes

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/5826/MinutesWSRMTC030204b.htm 
 
This includes corrections requested by Sunil.
 
Mail from Doug Bunting:
I do not believe I said "Doug: that packaging issue is fundamental to now." and do not understand the comment in the context of the minuted discussion in any case.  Please remove this line.
 
thanx,
    doug
 
Bob F  moved to accept the Mar 02 minutes, with deletion of line cited by Doug above. Jeff  seconded.
 
no opposition, 3/02  minutes approved with change.

 

3         Discussion of New Orleans Meeting and Conference

Need accurate count of who be attending meeting, and who will be staying in Conf Hotel:

 

Jacques needs to have one of represent the TC at the panel.

 

Do this over email.

 

4         Discussion of Issues

 

4.1      Rel 119

The following is the text for the new subsection on replyTo attribute

(this was sent by Sunil to me)::

 

The section for this attribute will look like this:

 

  ---------------------

  (1) replyTo attribute

 

  This attribute, of type URI, MAY be included by the sending RMP. If present, then the  receiver MUST send the RM-Reply   in an underlying request to the value of the URI. If not present, the RM-Reply MUST be sent back in  the underlying response of the Poll request itself.

  ---------------------

 

  -Sunil

>>

>>If we do accept this, here are the  changes that we need to do.

>>

>>

>>   1. Add an optional replyTo attribute to PollRequest

>>

>

> This is the schema thing, I've taken care of it.

>

>

>>   2. pg 6/line 177: Remove the replyTo attribute for Poll pattern in

>>Request  (this may contradict to what I said in the editorial comments...)

>>

>

> This change was done in v 0.991.

>

>>   3. pg 7/line 212:Title of Example 3 would read "Acknowledgment

>>Message embedded in HTTP Request"

>>

>

> This change is not needed if the example doesn't use replyTo attribute

> on Pollrequest.

>

>>   4. pg 7/line 213:HTTP Headers will have to change (should use POST)

>

>  This change is not needed if the example doesn't use replyTo attribute

>  on Pollrequest.

>

>>   5. pg 8/line 239:Title of Example 4 would read "Fault  Message

>>embedded in HTTP Request"

>>

>

> This change is not needed if the example doesn't use replyTo attribute

> on Pollrequest.

>

>>   6. pg 8/line 240:HTTP Headers will have to change (should use POST)

>>

>

> This change is not needed if the example doesn't use replyTo attribute

> on Pollrequest.

>

>>   7. pg 11/lines 334-339 should be reworded as follows:

>>

>>          We say that Polling RM-Reply pattern is used if a second

>>underlying request is issued to the  receiver of a previous message, in

>>order to obtain a RM-Reply. The RM-Reply can be either contained in the

>>underlying response to this poll request or in a separate underlying

>>request from the receiver to the sender. This poling pattern is

>>generally expected to be used in situations where it is inappropriate

>>for the sender of reliable messages to receive underlying protocol

>>requests (behind the firewall cases) or to avoid resending bulk messages

>>often.

>>

>

> This is the exact change that needs to be done. However, in v 0.991 this

> corresponds to lines 331-336. Replace these lines with the above one.

>

>>   1. pg 15/Figure 3. The 3rd line should be titled "Underlying protocol

>>Response/Request".

>>

>

> This is the exact change that needs to be done.

>

>>   2. pg 28/section 4.3

>>   

>

>>         1. Table 9: Add an optional attribute call replyTo of type anyURI

>>

>

>  This is the exact change that needs to be done. Add an attribute by name

> replyTo (anyURI) in row 3.

>

>>         2. We need to mention that RM-Reply MUST be contained in the

>>underlying response of the Poll request if this attribute doesn't exist

>>and should be sent  in an underlying request to the endpoint identified

>>by this attribute if exists.

>>

>

> Append  the sentence "RM-Reply MUST be contained in the

>underlying response of the Poll request if the replyTo  attribute doesn't exist

>and should be sent  in an underlying request to the endpoint identified

>by this attribute if exists." to the sentence ending on line 838 (in v0.991 draft).

>

>

>>   3. And finally the schema has to reflect this  by adding an optional

>>attribute to the PollRequest element.

>>

>

> This was taken care.

>

> Nothing else needs to be changed unless we need a Poll example showing replyTo.

>

> -Sunil

Iwasa stated he can reflect these changes.

Do not change the examples to reflect the new use of poll.

4.2      Rel 78

Rel 78 -

Title: Meet Compatibility, R8.1 requirement

Description: The Specification should be usable with other open standard

technologies, if appropriate.

R8.1.1   The Specification shall not preclude the use of Web Service

message attachments. (see also issue REL-10)

R8.1.2  Insure that the Specification is usable in combination with WSS

SOAP Message Security to implement secure reliable messaging. (see also

issue REL-25)

 

 

 

---

 

Upon a reading of the wss spec, I find no requirements on soap headers

for use with wss security headers.

 

Thus, I propose that we close Rel 78 with no change to the document.

 

Tom Rutt

Iwasa moved to close 78 with no change, Bob F seconded.

 

No opposition, motion passes.

4.3      Rel 77

Title: Meet Realization, R7.4 requirement

Description: The Specification must describe the semantics of Reliable

Messaging processing parameters that affect both sides of the protocol.

 

At the last f2f meeting the following was recorded in the minutes:

"

 

Proposal: To eventually close as accommodated by WS-Reliability spec

 

Resolution: Leave open, and close after we consider adding state charts

or state tables for sending and receiving reliable messages.

 

"

 

The state charts were used to verify the protocol.  However, they are

not required to be put in the spec, since the current

behaviour is adequately specified for both sender and receiver RMPs.

 

I propose we close this issue with no changes to the specification.

 

Tom Rutt

Bob: this issue can be closed, however some issue can be found.

Bob moves that we close this issue without change to doc, Jishnu seconded.

 

No opposition, motion passes.

4.4      Rel 92

The following text was proposed by Jacques at the last F2F meeting, but

did not have a formal resolution attached to it.

 

I propose we resolve Rel 92 by adding the following conformance clause,

just before the existing section 7 (references).

 

"

7   Conformance

 

In order to be conform to this specification, an implementation must satisfy all the following conditions:

 

·  It complies with the following interpretation of the keywords OPTIONAL and MAY:  When these keywords apply to the behavior of the implementation, the implementation is free to support these behaviors or not, as stated in [RFC2119].

 

·  If it has implemented optional features and/or behavior defined in this specification, it MUST be capable of interoperating with another implementation that has not implemented the optional syntax, features and/or behavior.  It MUST be capable of processing the prescribed failure mechanism for those optional features it has chosen

to implement.

 

·  If it has chosen NOT to implement optional features, it is capable of interoperating with another implementation that has chosen to implement these. It MUST be capable of generating the prescribed failure mechanism for those optional features it has chosen to NOT implement.

"

 

Jacques moved to accept this conformance clause to be added to spec, Iwasa seconded.

 

NO opposition motion passes close 92.

4.5      Rel 104

REL-104        

    Title: Spec and schema conflicts

    Description:   Is the spec or schema normative when they are in

conflict?

 

I propose we close this issue by placing a statement in the specification

 

"In a case where the text of the specification is shown to be in conflict with schema statements, the Schema statement prevails." 

 

Jeff M moved , Jeff T seconded.

Jacques: it is arbitrary to take the side of the schema.

Jeff M: I agree it is arbitrary as long as we pick one.  I would rather have a bug than an ambiguity.  It is often easier to find problems in the schema.

Doug: I agree, and would go one step further, that the text of the document tends to be things that coders interact with directly, while the schema is used by other tools.  I agree with the schema.

Jeff T: I use the schema as the basis for implementation.

Jacques: it is not a major issue, but if the schema has a problem, you pick it.

Jeff T: the schema can be the defininitive thing.for the structure of the message

Jacques is opposed.

All others for.  Motion passes, with one opposition.

4.6      New Issue on Reliability Container Element

From a later email from Jacques:

Where would spec 0.991 be affected if we wrap all reliability elements inside a single

"Reliability" child element of the SOAP Header:

----------------------------------------------------------------------------------

 

Examples 1, 2, 3, 4:

Wrap "Request" - and every other rel element -  within a common "Reliability" element.

 

Fig 5 and 6:

Add the Reliability element wrapping all RM elements.

 

L669:

Sentence is wrong, based on definition of "reliable message" in Terminology.

Replace:

"In a reliable message, the following three elements are direct children of SOAP Header:"

with:

"In a message, header elements related to reliability features are always contained in a

Reliability element.  The Reliability element is a direct child of the SOAP Header.

Any of the following three elements can be direct child of the Reliability element:"

 

L1161: Examples 9, 10, 11, 12, 14, 15, 16:

Add the Reliability element for wrapping Response or Request, etc. elements.

 

L1393:

"The first MIME part MUST... include SOAP Envelope with the Reliability element."

 

Change the Schema.

 

This proposal does not address the

 

Jacques: Several other web service specs pack everything into a single header block.  WSS does this.  This makes things cleaner on the implementation side.  All the elements we defined today would fit into a container.

 

Jacques: always having the same well recognized element is the main advantage.

 

Hamid: the message type is very important.  The RMP checks what type of message it is.  This is determined by the message type thru parsing the headers.  It is a heavy load to parse the headers fast.  Having one single container speeds the search process.  The different versions of the spec could be in that header.  The single container facilitates taking that header out of the message.

 

Anish: however if the two header elements are target to to different RMP processes, it would be better to have them separate.

 

Hamid:  I want to put the version of the spec in the header element.

 

Tom : we currently have the version of the spec in the namespace.

 

Hamid: But that does not have to be true.

 

Doug: perhaps we should make it true.  Require a new schema for new protocol versions.

 

John Fuller:  I thought it would be easier if the objects were contained in a consistent element type.  EBMS 2 had it in a single container, but decided to do it different due to soap 1.2 extensibility.

 

Jeff: If this imposes implementation constraints, I am concerned.  What if the rmp is implemented in a distributed manner.

 

Jeff: what does the soap processing model tell you that you have to do.

 

Jacques: I guess we have not given enough discussion of having different soap actors processing a piggybacked response.  

 

Hamid: there are three separate issues. One is a wrapper to ease parsing, and the other is the need for a version attribute in this header.

 

Jacques:  This issue needs more discussion.

 

Agreed to have issue editors Record as a new technical issue.  Title: “Need fo An additional container called reliability with an attribute for the version of the spec”.    

 

The writers of the spec can decide that the schema signals the version of the spec.

 

Tom: we could add statements.

 

New issue recorded to be discussed further.  How is the protocol version indicated for future versions, and the need for a common reliability header container element.

 

Members asked Hamid and Jacques to come up with a complete proposal for discussion by the group.

 

4.7      Issue 49 WSDL Annotation

 

Re: [wsrm] Rel49
From Anish Karmarkar <Anish.Karmarkar@oracle.com> on 8 Mar 2004 18:32:05 -0000

 

another proposal from Anish and Jacques, to resolve discussions in above mail, before the meeting:

All:

 

Here is a reviewed version of Anish WSDL annotation (inspired from F & P) initial proposal for WS-Reliability.

(Anish agreed with my review, after a few iterations between us...)

It has been now focused more narrowly to the use of Reliable features and capabilities.

I think each feature in it has proved useful for our purpose, and does not define more than what we need.

The mechanism is indeed quite flexible (I have more use cases to show this).

 

Jacques

<<ws-reliability-wsdl-annotations-final.txt>>

 

 

 

WS-Reliability Features, Properties and Compositor Proposal

-----------------------------------------------------------

 

I. Introduction

 

Users of a Web Service will need to be aware of the reliability capabilities

(RM capabilities)that are supported/required by the service. One practical location to

advertise these capabilities is in the service description (WSDL document),

which allows for publishing both abstract service definitions as well as

concrete protocol details (bindings). This allows clients (or other Web

services) to easily obtain information about specific capabilities such as

guaranteed delivery, duplicate elimination, message ordering, and various

reply patterns of a specific Web service, before calling the service.  While

bundling reliability capabilities with the service description may not be

desirable in all cases, it is expected that this convenient approach will

often be appropriate. The WSDL annotation mechanism described here is a

flexible way to add such capability assertions.

 

WS-Reliability 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 service to advertise its capabilities, and

composibility of those capabilities.

 

The following extensibility elements relevant to RM capabilities are used:

 

 * feature - abstract RM capability or assertion associated with WSDL elements.

 * property - an assertion or constraint on an atomic RM capability and its value(s)

associated with WSDL elements.

 * compositor - specify how features and properties are combined.

 

An annotation composed with the above extensibility elements will specify the

reliability features and properties associated with specific WSDL constructs.

Features and properties represent reliability capabilities and compositors

specify how these capabilities are composed.

 

This would allow, for example, a Web service description to advertise the fact

that clients invoking the service must use duplicate elimination or message

ordering.

 

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.

 

I.B Conformance

 

Implementations of WS-Reliability are expected, though not required, to

understand the WSDL extensibility points defined in this section.

 

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.

 

II. WSDL Extensibility Elements

 

II.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 usage of composed elements

by a client to the service, is required or optional.

The RM capabilities represented by these elements must all be supported by the Service.

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), wsdl11:binding, wsdl11:service and wsdl11:port. 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="..." name="NCName"?>

   [fnp:feature/> | <fnp:property/> | <fnp:compositor/> |

    <extensibility-element/>]+

</fnp:compositor>

 

The uri attribute of the compositor specifies its semantics. Four different

compositors (URIs) and their capability-related semantics are described

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. The optional name attribute identifies the compositor. An

element built with such compositors represents an RM capability.

 

1. all: this compositor specifies that a service invocation MUST comply with

all the children elements (representing RM capability assertions). 

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 a service invocation MUST comply with

exactly one of the possibly many children elements (representing RM capability assertions).

   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 a service invocation MUST comply with

at least one of the possibly many children elements (representing RM capability assertions).

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 a service invocation MAY comply with

one or more of the children elements (representing RM capability assertions).

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 VII below.

 

Compositors specified at different WSDL components are implicitly aggregated

using the 'all' compositor at the dependent WSDL component. Consider the example

below,

 

<wsdl11:definitions>

  ...

  <wsdl11:portType name="myPortType">

    <fnp:compositor uri="..." name="A">

      ...

    </fnp:compositor>

    ...

  </wsdl11:portType>

 

  <wsdl11:binding name="myBinding" type="myPortType">

    <fnp:compositor uri="..." name="B">

      ...

    </fnp:compositor>

    ...

  <wsdl11:binding>

 

  <wsdl11:service name="myService">

    <wsdl11:port name="myPort" binding="myBinding>

      ...

    </wsdl11:port>

  </wsdl11:service>

 

<wsdl11:definitions>

 

Compositor specified at the wsdl11:portType "myPortType" and compositor

specified at wsdl11:binding "myBinding" are aggregated at the dependent

wsdl11:port "myPort" using the 'all' compositor. I.e., the equivalent

compositor at "myPort" is,

 

<fnp:compositor

uri="http://www.oasis-open.org/committees/wsrm/schema/1.1/fnp/compositor/all">

  <fnp:compositor uri="..." name="A">

  </fnp:compositor>

  <fnp:compositor uri="..." name="B">

    ...

  </fnp:compositor>

</fnp:compositor>

 

II.B Feature

 

A feature describes an abstract RM capability or assertion associated with a WSDL

element. A feature can occur only as a child of a compositor.

Whether the usage of 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 is an assertion or constraint on

a specific RM capability and its value(s) associated with WSDL elements.

Typically properties are associated

with a feature (but are not required to) and are described 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. 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.

 

IV. 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/"

 

IV.A. Guaranteed Delivery Property

 

This property is identified by the QName "wsrm:GuaranteedDelivery" and

corresponds to the semantics specified by the WS-Reliability guaranteed

delivery semantics. The type of this property is "xs:boolean".

 

IV.B. Duplicate Elimination Property

 

This property is identified by the QName "wsrm:NoDuplicateDelivery" and

corresponds to the semantics specified by the WS-Reliability duplicate

elimination semantics. The type of this property is "xs:boolean".

 

IV.C. Message Ordering Property

 

This property is identified by the QName "wsrm:OrderedDelivery" and

corresponds to the semantics specified by the WS-Reliability message

ordering semantics. The type of this property is "xs:boolean".

 

IV.D. Reply Pattern Property

 

This property is identified by the QName "wsrm:ReplyPattern" and

corresponds to the semantics specified by the WS-Reliability reply

pattern options. The type of this property is "xs:String".

(values: Response, Poll, Callback)

 

 

V. Other Reliability Properties

 

In addition to the properties defined in section III, there are

WS-Reliability properties that are used on the Sender side (usually the client side

and therefore do not occur in the WSDL document).

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.

 

V.A. Group Expiry Time

 

This property is identified by the QName "wsrm:GroupExpiryTime" and

corresponds to the semantics specified by the WS-Reliability group expiration

time. The type of this property is xs:duration.

 

Note: The expiry time is calculated at the time a message is sent, but adding

this duration to the time the message is sent.

 

V.B. Group Maximum Idle Duration

 

This property is identified by the QName "wsrm:GroupMaxIdleDuration" and

corresponds to the semantics specified by the WS-Reliability group maximum idle

duration. The type of this property is xs:duration.

 

V.C. Message Expiration Time

 

This property is identified by the QName "wsrm:ExpiryTime" and

corresponds to the semantics specified by the WS-Reliability message expiration

time. The type of this property is xs:duration.

 

Note: The expiry time is calculated at the time a message is sent, but adding

this duration to the time the message is sent.

 

V.D. Retry Maximum Time

 

This property is identified by the QName "wsrm:RetryMaxTimes" and

corresponds to the semantics specified by the WS-Reliability maximum retry

times. The type of this property is xs:int.

 

V.E. Retry Time Interval

 

This property is identified by the QName "wsrm:RetryTimeInterval" and

corresponds to the semantics specified by the WS-Reliability retry time

interval. The type of this property is xs:duration.

 

V.F. ReplyTo URI

 

This property is identified by the QName "wsrm:ReplyTo" and

corresponds to the semantics specified by the WS-Reliability reply-to.

The type of this property is xs:anyURI.

 

VI. 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="GuaranteedDelivery" type="xs:boolean"/>

    <xs:element name="NoDuplicateDelivery" type="xs:boolean"/>

    <xs:element name="OrderedDelivery" type="xs:boolean"/>

    <xs:element name="ReplyPattern" type="xs:string"/>

 

    <!-- properties to be used on the client side -->

    <xs:element name="GroupExpiryTime" type="xs:duration"/>

    <xs:element name="GroupMaxIdleDuration" type="xs:duration"/>

    <xs:element name="ExpiryTime" type="xs:duration"/>

    <xs:element name="RetryMaxTimes" type="xs:int"/>

    <xs:element name="RetryTimeInterval" type="xs:duration"/>

    <xs:element name="ReplyTo" type="xs:anyURI"/>

 

</xs:schema>

 

VII. Examples

 

VII.A Example for the "all" compositor

 

<wsdl11:portType name="Example-1">

  <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:DuplicateElimination">

          <fnp:value>true</fnp:value>

        </fnp:property>

        <fnp:property name="wsrm:OrderedDelivery">

          <fnp:value>true</fnp:value>

        </fnp:property>

        <fnp:property name="wsrm:GuaranteedDelivery">

          <fnp:value>true</fnp:value>

        </fnp:property>

      </fnp:compositor>

    </fnp:feature>

  </fnp:compositor>

  ...

</wsdl11:portType>

 

In the example above, the reliability feature identified by URI

"http://www.oasis-open.org/committees/wsrm/schema/1.1/feature/rel/" is

required by the portType. This feature consists of three properties, all of

which are required because of the semantics of the 'all' compositor that

composes the three properties.

 

VII.B Example for the "choice" compositor:

 

<wsdl11:binding name="Example-2">

  <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/compositors/choice">

        <fnp:property name="wsrm:ReplyPattern">

          <value>Response</value>

        </fnp:property>

        <fnp:property name="wsrm:ReplyPattern">

          <value>Callback</value>

        </fnp:property>

        <fnp:property name="wsrm:ReplyPattern">

          <value>Poll</value>

        </fnp:property>

      </fnp:compositor>

    </fnp:feature>

  </fnp:compositor>

  ...

</wsdl11:binding>

 

In the example above, the reliability feature identified by URI

"http://www.oasis-open.org/committees/wsrm/schema/1.1/feature/rel/" is

required by the portType. This feature consists of three properties, of which

the client must choose one.

 

VII.C Example for the "one-or-more" compositor:

 

<wsdl11:portType name="Example-3">

  <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/one-or-more">

        <fnp:property name="wsrm:DuplicateElimination">

          <fnp:value>true</fnp:value>

        </fnp:property>

        <fnp:property name="wsrm:OrderedDelivery">

          <fnp:value>true</fnp:value>

        </fnp:property>

        <fnp:property name="wsrm:GuaranteedDelivery">

          <fnp:value>true</fnp:value>

        </fnp:property>

      </fnp:compositor>

    </fnp:feature>

  </fnp:compositor>

  ...

</wsdl11:portType>

 

VII.D Example for the "zero-or-more" compositor:

 

<wsdl11:portType name="Example-4">

  <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/zero-or-more">

        <fnp:property name="wsrm:DuplicateElimination">

          <fnp:value>true</fnp:value>

        </fnp:property>

        <fnp:property name="wsrm:OrderedDelivery">

          <fnp:value>true</fnp:value>

        </fnp:property>

        <fnp:property name="wsrm:GuaranteedDelivery">

          <fnp:value>true</fnp:value>

        </fnp:property>

      </fnp:compositor>

    </fnp:feature>

  </fnp:compositor>

  ...

</wsdl11:portType>

 

Jacques: I am now happy with the proposal above, and his concerns have been resolved.

 

Anish: Jacques and I went over a few iterations.  There is now one proposed annex, not two annexes.  It makes it focused to WS-Reliability, and rm capabilities.  It now is written as a proposal specific to WS-Reliability.

 

Jacques:  People have seen the earlier proposal, and have seen my concerns.

 

Marc G: I am still opposed to this.  We are going in our own direction here.  The wsdl 2 group could (and I believe already is) move in different directions.  I do not believe we should be addressing this.

 

Iwasa stated he agrees with Marc G.

 

Tom: It was stated in our original charter.

 

Marc G: I believe the earlier decision on Rel 14 was the correct one, to put this off for a future version of the spec.

 

Anish: Perhaps one could view this as shortsighted, the other is that it is a stopgap approach.  Most vendors key things off the wsdl spec.  People have had to cobble together wsdl to interoperate.

 

Jishnu: I seem to remember our discussion that the entire thing is optional.

 

Anish: Tool support for these extensibility points will facilitate interoperability.

 

Marc: I am concerned about us backporting this mechanism in our spec.  It is more general in nature. 

 

Motion on Rel 14, and Rel 49:  Resolve both of these by incorporating the proposal above as a normative annex to the spec.

 

Jeff M moved , jishu seconded to resolve rel 14 and 49 with this proposal being added to the spec as a normative annex.

 

Marc G objects

Iwasa obstains.

Marc Peel abstains

11 members accept proposal.

 

Motion passes with one objection.

 

 

0         Discussion of Editorial Comments.

Editorial Comments for Discussion

Sunil Kunisetty wrote:

 

 

 Iwasa,

 Here are some technical comments (need discussion):

1.      pg 13/Line420, Why are RetryMaxTimes and RetryMaxInterval MUST for GD. Shouldn't it be MAY?

 

The scope is defined in terms of memory.  Most would provide these at the group scope.  

The resending mechanism is part of the spec.

 

It has questions about the meaning of message scope.  The protocol will work if the second bullet is removed. 

 

If we should not preclude irregular retry intervals, then we should reconsider this configuration parameter.

 

Jacques: all we need is to not send beyond expiry time. 

 

Hamid: these resend techniques may need to be configured dynamically.

 

Tom Suggested to delete the lines 420 and 421.


 Still exists in v 0.991

1.      pg 6/Line 177: Currently,  when using Poll pattern, replyTo attribute is not needed. However, we have an open issue. So don't change this until we decide one way or other.

  done

1.      pg 16/line 493:I don't think we should say that retries are MUST especially when we have Poll mechanism now. Sender can alternatively Poll the message

 

NO accept as editorial.


 still exists .... same line no.

1.      pg 25/line 751: Shouldn't the MUST be changed to SHOULD in this case just as in line 743 d

2.      d

Not accept as editorial

 still exists .... same line no.

1.       

 Here are some editorial comments:
 

1.      pg 4/line 74: SOAP 1.1 should be a non normative reference as it is not a specification rather just as W3C Note. Btw SOAP12 should be normative.

 still exists .... same line no.

1.      pg 5/line 142:I believe we are not defining any extensions to SOAP Body. Also, we are not defining extensions to SOAP Header element per say, rather defining SOAP Headers needed for the protocol

 still exists .... same line no.

1.      pg 6/line 152. We may need a normative reference to WS-I BP and non normative reference to WSDL 1.1

 still exists .... same line no.

1.      pg 6/Line 177: Change the replyTo to some what meaningful URI, say http://wsr-example.org/mylistener or something similar


 NA

1.      pg 12/line394: Shouldn't s3 say "A single message, standalone (singleton) or within a group of several message (non singleton group)".


 still exists. new line no. is 395
 
 

1.      pg 12/line 397: Didn't fully understand the last sentence (Such scopes are "required" scopes that must be supported). Good to clarify this.

 still exists. new line no. is  398

1.       

2.      General comment: we need to correlate the agreement items with elements in our protocol, i.e., for ex., we need to say that the agreement item GuaranteedDelivery is supported when the <AckRequested> element exists. If we don't say this, then there will be a 'gap', although some of them may sound implicit.


 still applies

1.       

2.      pg 14/lines 437-441: I'm bit cautious about the 2nd paragraph of Messaging Context... At this time, I don't have specific comments, but I'll revisit this.


 still applies

1.       

2.      pg 19/line 571 etc.. We use the prefix RM often, but doesn't explain clearly what RM is defined too.


 still applies

1.       

2.      pg 19/line 584: Doesn't the outside box (the one referred by Response) should be bold (i.e.  required)


 still applies

1.       

2.      pg 20/line 600: For Poll request, child name under PollRequest should be RefToMessageIds and not MessageId


 still applies

1.       

2.      General comment: Remove the Fault row from element descriptions


 still applies

1.       

2.      pg 22/line 654:Response pattern should not have replyTo attribute


  still applies

1.       

2.      pg 26/line 791: The type of replyTo should be URI and not URL


 still applies

1.       

2.      pg 26/line 797: The type of replyTo should be URI and not URL ( we could say that it could be URL in Http case).


 still applies. line 795

1.       

2.      pg 26/line 804: Change MUST send an Acknowledgment message to "MUST send an RM-Reply" (as it could result in a fault too)


 N/A

1.       

2.      General comment: mustUnderstand attribute in element tables should have the type (boolean) in the parenthesis just as other attributes


 still applies

1.       

2.      pg 30/table 12: replyPattern should have the type in parenthesis


 still applies

1.       

2.      pg 31/line 939: we no longer have the Response as default for this attribute. so remove that line.


 still applies. line 935

1.       

2.      pg 33/section 4.4.2.1/line 972 should be titled ReplyRange and not ReplyPattern


 done.

1.      pg 33/table 15: fault should have the type (QName) in parenthesis


 still applies

1.       

2.      pg 34/line 1008: "Thus a ReliableMessagingFault could come in" should be changed to "Thus a response may have a"


 still applies. new line. is 1005

1.       

2.      pg 36: We need to remove the lines 1039,1040,1041


 still applies

1.       

2.      pg 37: we need to remove the lines  1049, 1050, 1051

 still applies

 
 -Sunil

 

 

Iwasa is to incorporate the editorial items (not ones with questions or changing MUST TO SHOULD) from Sunil’s comments above.

The following editorial comments were agreed to be included in the next draft of the spec.

 

1         Timing of WS-Reliability progression

 

Potential Vote for release of Committee Draft 6 day ballot:

 

Initiating 5:00 PM Eastern Time Wednesday Mar 10, 2004

Closing 5:00 PM Eastern Time Tuesday Mar 16, 2004.

 

Could schedule a vote to start pubic review at Mar 16 TC teleconference.

 

Bob moved we put the document as prepared by Iwasa to resolve the agreements in these minutes out for 6 day  kavi ballot., to close just before the next WSRM TC meeting..  Jeff M seconded

 

No opposition.  Motion passes.

 

We will schedule a vote to release for public review at the next meeting.

 

Meeting was adjourned at 7:12 PM Eastern Time.

 

 



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