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

Attendance:

First Name	Last Name	Role	Company
Jacques	Durand	Secretary	Fujitsu Limited*
Tom	Rutt	Chair	Fujitsu Limited*
Robert	Freund	Voting Member	Hitachi, Ltd.*
Eisaku	Nishiyama	Voting Member	Hitachi, Ltd.*
Nobuyuki	Yamamoto	Voting Member	Hitachi, Ltd.*
Paul	Knight	Voting Member	Nortel Networks Limited*
Anish	Karmarkar	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:

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/17673/MinutesWsrmTC-040406.htm

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:

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/12436/wsReliabityFutureFeatures.htm

TC needs to decide among the following possibilities

work to resolve new issues raised within charter of TC,
put the tc into maintenance mode (i.e., two meetings a year awaiting usage issues),
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

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.

wsrm message