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 7/11 teleconf

Prelim minutes are attached.

Please provide corrections to entire list before monday morning.

Tom Rutt
wsrm TC Chair

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 – 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


First Name

Last Name






Fujitsu Limited*




Fujitsu Limited*



Voting Member

Hitachi, Ltd.*



Voting Member

Hitachi, Ltd.*



Voting Member

Nortel Networks Limited*



Voting Member

Oracle Corporation*




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:




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


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.”


“… 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:

“ General case”


After Line 561: add:


“ 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.”


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.

7          New Business

Meeting adjourned


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