Prelim Minutes WSRM TC Conference Call – July 11, 2006

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.*
Nobuyuki	Yamamoto	Voting Member	Hitachi, Ltd.*
Paul	Knight	Voting Member	Nortel Networks Limited*
Anish	Karmarkar	Voting Member	Oracle Corporation*
Pete	Wenzel	VotingMember	Sun Microsystems*

Meeting is quorate

3 Minutes Discussion

Tom Rutt volunteered to take minutes.

3.1 Approval of previous meeting minutes

The minutes of the June teleconference meeting are posted at: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/19030/Minutes-wsrmTC-061306.htm

Bob F moved to approve the June minutes, Paul K seconded.

No opposition June 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.

Posted as: http://www.oasis-open.org/apps/org/workgroup/wsrm/email/archives/200606/msg00004.html

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 May meeting: Reliability of Request-Responses

Jacques finished his action item to specify the exact changes needed to ws-reliability 1.1.: posted contribution as:

http://www.oasis-open.org/apps/org/workgroup/wsrm/email/archives/200606/msg00004.html

A simple proposal for reliability of the response over back-channel:

----------------------- (on final Nov 15 2004 version (pdf))

Line 273-274 (definition of Respond) replace with:

“An abstract operation that transfers a payload as a response to a previously received

request message, back from the Consumer of this request to the Receiving RMP of the request.

In case a two-way underlying protocol is used, the response message submitted using this

operation is transmitted over the back-channel of the related request message.”

Line 276-278 (definition of Notify) replace the following:

“…or transfers a payload received as a response from Sending RMP to Producer.”

With:

“… or transfers a payload received as a response (submitted via Respond) to a

previous request, from the Sending RMP of this request to the Producer of this request.”

After Line 532 (below 3.2.1 title) add subtitle:

“3.2.1.1. General case”

After Line 561: add:

“3.2.1.2. Case of a Response Message”

“This concerns the messages submitted via the operation Respond, when a two-way

underlying protocol is used.”

“Quality of Service Requirements:”

“When the GuaranteedDelivery Agreement Item is enabled for a response message submitted

via the Respond operation, the following conditions must also be satisfied:

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

Either one of the following outcomes must occur:

(1) the response-receiving RMP successfully delivers the response message to its associated

Consumer or

(2) the response-receiving RMP notifies its associated Consumer of an exchange failure,

meaning either the request or the response message failed to be delivered. In this case,

an additional delivery failure to the response-producer party by the response-sending RMP may occur.”

“Protocol Requirements:”

“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

by the RMP on the back-channel of any request duplicate that is received by this RMP.

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 Respond invocation,

may or may not contain a wsrm:Request element. If the Response message includes a

wsrm:Request element with an AckRequested element, then it must use Callback RM-Reply Pattern.”

Line 568-569: replace:

“An extension of this agreement to messages resulting from invocations to the Respond operation is

out of scope for this specification.”

With:

“this agreement can easily be extended to response messages sent over a back-channel: the

submission is done via Respond (instead of Submit) and the delivery uses Notify (instead of Deliver).”

Jacques presented his proposal to the TC. In definition of guaranteed delivery:

qos aspect (DA) has changed a little bit.
Protocol aspect has not changed, no schema or message header contents changed.
Behaviour of RMD, with respect to api notifications and caching has changed a little.

Tom noted that such a revision would require no schema or namespace changes.

Tom asked Jacques how we could progress such a change, (say in a new minor version which includes the errata and the new behavior).

Jacques: this is a minor revision to the protocol, since no changes are required to the messages. I would not like to make a big case of it. If this upgrade gets to CD status, that would be sufficient.

Tom: that would not even require public review, if we did not want a CS.

There were no objections to the idea.

ACTION: Tom to produce editors draft. 1.1.1, incorporating errata and Jacques proposal.

6 Future Meetings

Next meeting Sept 5, 5:30 – 6:30 EDT.

wsrm message