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 5/16 meeting

Prelim minutes are attached, please provide correction before next monday.

Tom Rutt

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

Title: Full Agenda for WSRM TC Conference Call –June 14, 2005

Prelim Minutes WSRM TC Conference Call – May 16, 2006


The meeting of the WSRM  TC took place by teleconference 

Time         Tuesday, 16 May 2006, 05:30pm to 06:30pm ET

1          Draft Agenda:

1) review agenda

2) Roll Call

3) Minutes approval

4) Action Items

5) Discussion of potential TC future activities

5.1 Reliability of Response

6) New Business

2          Roll Call


First Name

Last Name






Fujitsu Limited*




Fujitsu Limited*



Voting Member

Hitachi, Ltd.*



Voting Member

Hitachi, Ltd.*



Voting Member

Hitachi, Ltd.*



Voting Member

Nortel Networks Limited*



Voting Member

Oracle Corporation*




Meeting is quorate


3          Minutes Discussion


Tom Rutt Volunteered to take minutes.


3.1       Approval of previous meeting minutes


The minutes of the 4/4 teleconference meeting are posted at:



Bob F  moved to approve the 4/4   minutes, Paul Knight  seconded.


No opposition  4/4  minutes are approved


4          Status of Action Items

2006-02-21-3 - Closed

Action: Jacques will clarify what he thinks we should do on reliability of req-resp.


5          Discussion of Potential Future TC activites

The working list of potential enhancements to WS-Reliability was posted after the last f2f as:




TC needs to decide among the following possibilities

  1. work to resolve new issues raised within charter of TC,
  2. put the tc into maintenance mode (i.e., two meetings a year awaiting usage issues),
  3. schedule vote to disband TC


5.1       Reliable Request Response

Jacques posted the following contribution before the last meeting: Reliability of Request-Responses


Jacques was given action item to propose detailed changes required to ws-reliability v1.1, Investigating the update needed for reliability response messages (guarateed delivery), for users who need it:


Quality of Service definition:


When the GuaranteedDelivery Agreement Item is enabled for the response message in a request-response MEP, the following conditions must also be satisfied:

-          GuaranteedDelivery and DuplicateElimination are also enabled for the request message.

One of the two following outcomes SHALL occur for each SubmitResponse invocation that follows a successfully delivered SOAP request message: either:

 (1) the Response-receiving RMP successfully delivers (DeliverResponse invocation) the payload to its associated Consumer or

(2) it notifies (Notify invocation) the Response-consumer of a delivery failure for the response.

 In case (2) an additional delivery failure to the Response-producer by the Response-sending RMP may occur.



Functional and Protocol Aspects:


After receiving a request message, and if a response message has been previously sent over the back-channel for this request, then the same response message MUST be sent again on the back-channel of any request duplicate that is received. This assumes that the initial response is cached (until expiration or until it is acknowledged, whichever comes first.)

The request message submitted with Submit operation, must use the wsrm:Response RM-Reply Pattern. When under GuaranteedDelivery, the response message resulting from SubmitResponse invocation, may or may not contain a wsrm:Request element. If the Response message includes a wsrm:Request element, this element must use Callback RM-Reply Pattern with AckRequested element.




Jacques: This proposal leaves out ordered delivery and does not mention duplicate elimination of response.  Focus on guaranteed delivery of response.  If the response wants guaranteed delivery, the request must have guaranteed delivery and duplicate elimination.  The failure indication goes to the request initiator.  There is no requirement for notification to response sender.  The request sender can overcome the failure by resending the request.  The caching of response messages is made mandatory for reliability of response.


Anish: If you have guaranteed delivery and duplicate elim on request, why must the cached response be send back.


Jacques: duplicate elimination is about delivery.  The Receiver can process a duplicate request without redelivering to the receiver of the request.


Anish: So the receiving end is responsible for sending cached response on the duplicate request.


Jacques: yes.  The current spec allows this behaviour, however this two way reliability requires another constraint.

Jacques: The final response may or may not be acknowledged, if so it must use callback reply pattern.


Tom: what would be required for the qos request on first message for groupID?


Jacques; we could extend the da signaling in the protocol.  Otherwise the only option it so assume that the response would be signaled out of band in destination RMP in an unspecified manner.


Tom: the protocol change are adding requirement for caching) and perhaps the DA signaling for reliability on Response.


Tom: is a new version required?


Jacques: if new da signaling is required, we would need an extension.  However this is minimal.  For implementations, caching the response is the major change required.

Paul K: the protocol would require a new notification for the model.


Tom: this does not affect protocol, but this is a new notification type for the model.


Tom: Could Jacques give a more detailed proposal on the additional da, and the changes required to the text in the spec


Jacques : I could do that for this restricted proposal.  I can afford to give a more detailed proposal.


Action: Jacques will provide a more complete proposal.

6          Future Meetings

June 13 as next meeting.


Jacques should have proposal available several days before meeting.

7          New Business



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