[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: email@example.com; firstname.lastname@example.org Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: 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
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.
The working list of potential enhancements to WS-Reliability was posted after the last f2f as:
TC needs to decide among the following possibilities
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