Prelim Minutes WSRM TC Conference Call –Jan 24, 2006

The meeting of the WSRM  TC took place by teleconference

Time Tuesday, 24 Jan 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

5.2 Delivery Assertions for Sequences

6) New Business

2 Roll Call

Attendance:

First Name	Last Name	Role	Company
Jacques	Durand	Secretary	Fujitsu Limited*
Kazunori	Iwasa	Secretary	Fujitsu Limited*
Tom	Rutt	Chair	Fujitsu Limited*
Robert	Freund	Voting Member	Hitachi, Ltd.*
Nobuyuki	Yamamoto	Voting Member	Hitachi, Ltd.*
Alan	Weissberger	Voting Member	NEC Corporation*
Paul	Knight	Voting Member	Nortel Networks Limited*
Anish	Karmarkar	Voting Member	Oracle Corporation*
Doug	Bunting	Secretary	Sun Microsystems*
Pete	Wenzel	Voting Member	Sun Microsystems*

Meeting was quorate.

3 Minutes Discussion

Tom Rutt Volunteered to take minutes.

3.1 Approval of previous meeting minutes

The minutes of the 11/29 teleconference meeting are posted at:

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/16386/MinutesWsrmTC112905-r1.htm

R1 posting added Jeff M to attendance list.

Bob F Moved to approve the 11/29 r1 minutes, Alan W seconded.

No opposition minutes 11/29 minutes approved

4 Status of Action Items

4.1 Action 012505-1 (Tom Rutt) Pending

OASIS Staff has posted the errata cd as:

http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/wsrm-ws_reliability-v1.1-errata-cd1.0.pdf

However, on the posted standard the errata index is referenced as as:

http://www.oasis-open.org/committees/wsrm/documents/errata/1.1/index.html.

The errata Index still does not yet exist.

The action item will stay open until the errata index page is posted.

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, - with a minimum of 4 members
put the tc into maintenance mode (i.e., two meetings a year awaiting usage issues),
schedule vote to disband TC

Insert of Late email posting from Fujitsu for discussion::

We propose 2 important work items for the WSRM TC going forward and one bonus benefit:

1. Clarify and unambiguously define the reliability of the response message.

We should not assume that this is equivalent to the reliability of the request message, but should define it separately and independently. We propose to include this in WS-R 1.2 - a small incremental addition to the existing spec.

While the reliability of the response should be defined in different terms than the reliability of the request (see proposal), it should not have a major impact on WS-R 1.1 standard or implementations. If the WS-R 1.1 implementation supports the option to cache the response and resend it, then all the functionality to support reliability of a synchronous response message is already present.

-->The WS-R specification should make that clear by defining the criteria for the reliability of the response message.

2. Develop a high level specification for delivery assurance/QoS of a reliable message. We need to define the notion of reliable message delivery assurance in the context of QoS by describing the precise semantics (but not the syntax or protocol). The standardization of the expression of delivery assurance could be used to support either WS-R or WS-RMg (WS-RX).

We believe that a "mark-up" of the standard representation of delivery assurance would be very valuable for the WS industry and would be more expediently developed, generated and approved in the WSRM TC (vs WSRX TC) due to its proposed sharper focus.

For example, we recommend distinguishing between an acknowledgement from the receiving RMg entity (e.g. in WS-RX spec) vs an acknowledgement that confirms that the layer above the receiving RMg entity (perhaps a WS control protocol or application layer) has correctly received the message from the RMg entity.

Also, there may be different notions of the various forms of reliable message delivery: at least once, atmost once (AKA duplicate elimination), guaranteed delivery, sequential delivery, etc. What do these notions really mean to the layer above? They need to be precisely defined and illustrated.

--------------------------------------------------------------------------------------------------------------------------

Side benefit:

By keeping the WSRM TC actively engaged by working on these two subjects, we also reserve one or more placeholder work items that could be initiated when other Web Services specs are more mature and able to be used with WS-R:

-Defining a minimal level of interoperability between WS-R and WS-RMg. For example, defining a common set of functionality or lowest common denominator between the two specs and a corresponding (run time) syntax translation mechanism for equivalent message types.

-Composing WS-R with WS-Addressing (for the SOAP binding case).

-Composability with other specs TBD (i.e. WS Resource Framework or WS-Notification family of standards)

-Consistency with ebXML version 3, which currently references WS-R.

Jacques summarized that this proposal has two potential work items which are within the scope of the wsRM tc, and are not being worked within another TC.

Jacques stated he expects discussion on the relevance of these items. He would like feedback before any formal votes.

The first item, on reliability of response has an initial contribution, to be discussed in 5.1 below. This does not require change to the WS-Reliability protocol but does extend the Delivery assurance specifications for reliability agreements.

Regarding the second work item on a DA framework specification, Jacques summarized the status of the WS-RX TC, which now has a clear separation between DAs and Protocol. He proposes some new work on DA which can apply to either WS-Reliability or WS-Reliable messaging. We have a need to specify it, at least for WS-reliability

Pete: What is the opinion of Jacques that these are within the charter of the TC.

Tom: I believe we should focus first on whether we need to have this work done in the TC, since they are broadly within the original charter.

Jacques: I would have to check the scope of the Charter.

Tom: we should move to the detailed discussion of each proposal below.

5.1 Reliable Request Response

Jacques posted the following contribution

130014

Groups - Reliability of Request-Responses (Reliable-Req-Resp-contribution.doc) uploaded

Jacques Durand

19 Jan 2006 21:30:33

Bob F: this could be within our charter, with a small cleanup of the spec.

5.2 Delivery Assertions for Sequences

The following is a chair proposal for discussion:

The OASIS WS-RX TC is working on a protocol which supports all the reliability Qos Features from WS-Reliability, but has no mechanism for associating DA levels with sequences on endpoints.

This TC, as a migration specification, could specify extensions to allow ws-reliability compatible association of DA levels with individual ws-Reliable messaging protocol sequences.

Before undertaking such a task, the TC could conduct a Survey of WS-Reliability implementers and Users to determine the importance of associating DA levels with individual reliability sequences.

Bob F: I think working on DA beyond the single protocol this group set out to is outside the scope. In particular, DA to work across multiple reliability protocols was not in our original scope.

Bob F: we could also get into discussions of what is meant by a guarantee, with application acknowledgement being an important aspect. With either of these two protocols the application is not well defined. Is the application separate from the design of the reliability mechanism, or integrated. That isolation complicates the determination of delivery assurance.

Bob F: I get touchy about expectations that can be derived from quality assertions along the lines of DA.

Alan F: whether the ack is from the RM process or the application could be clarified in this new specification of DA. What protocol could be used to distinguish, we did not discuss this.

Tom R: the real difference is not the details our protocols acking on receipt v sacking on Deliver, but is on the ability to assert DA levers per reliability sequence.

Bob F: the crux if the difference is whether the sender declares the DA requirements for a sequence, vs the Receiver always deciding. Part of my problem is that our DAs are seen as a sender responsibility. Somewhere there is a driver that makes a demand for application behaviour, then there is the actor that produces the behaviour.

Jacques: Regarding the scope of our charter for reliability Qos representation, we already have that in appendix 3B, on wsdl extensibility elements. Is that good enough, or could we just decouple this from the WSDL. Going beyond this protocol might not be in charter.

Jacques: I am also not sure that the essential difference between the two specs is on the source assertion of DA. The concern is whether we care about contracts between RMS and RMD?. Who asserts is not as important as whether there is shared knowledge of the contract between source and Destination

Tom R: when talking to Marc G, who was on our committee in the past, he asked how many users would actually be hurt by the additional delays when ordered delivery is in use when it is not needed.

Doug B: thinking in terms of Us vs Them is not really useful. With regard to this issue, it is not a question of one spec being better than another, but the real concern is whether any change to ws-reliability spec will be of use now or within two years from now. These questions seem to be of relatively low level, and may not matter to our customers..

Alan W: this proposal to have a new DA framework does not change the existing spec.

Doug B: but it is an enhancement to the WS-R spec family.

Bob F: thinking of what users of WS-reliability cannot do with the WS-RM spec is a question. How would their business be impacted.

Tom R: how could a TC determine what its users see as a necessity in the existing specificaiton, that they could not live without in an alternative spec.

Jacques: When we wrote WS-Reliability there were no questions as to its being asserted on each sequence. Whether this is an enhancement to an existing spec, or is a new work item to be don in a separate place. It remains the fact the working at protocol level is good thing, but there are OOS aspects beyond the protocol itself which may be of use.

Doug B: the reason why those bits of policy info has been removed from WS-RX spec is that they all assume a business protocol setup, which will come in the future business standards, layered above the Reliability spec.

Tom: the question is whether our users can live without the explicit knowledge of which DA is in use on a given Sequence. Just because our protocol does it does not mean they need the complexity. Can they live with having that determination totally outside our spec, as Doug D stated could be done in other application level specifications.

Jacques; the questions are whether this should be done in wsdl, was originally an issue.

Bob F: WS-reliability is done. Are we trying to change ws reliability or are we trying to enhance the other TC’s spec. A question of clarification to Jacques, is whether assertion type things that apply to other specs (like application contracts or BPEL) is the way to go.

Jacques It is a matter of distinguishing syntax and semantics. We could define concepts, with the representation in a more general language.

6 Future Meetings

At last meeting, TC agreed to decide on the next meeting at this meeting.

Agreed to next Meeting Feb 21 Tuesday for one hour 5:30 PM to 6:30 PM Eastern Time..

wsrm message

1 Draft Agenda:

2 Roll Call

3 Minutes Discussion

3.1 Approval of previous meeting minutes

4 Status of Action Items

4.1 Action 012505-1 (Tom Rutt) Pending

5 Discussion of Potential Future TC activites

5.1 Reliable Request Response

5.2 Delivery Assertions for Sequences

6 Future Meetings