Full Agenda WSRM TC Conference Call –Jan
24, 2006
The meeting of the WSRM TC will take place by teleconference
Time
Tuesday, 24 Jan 2006, 05:30pm to
06:30pm ET
Description
Host: Fujitsu
Toll only :
1-512-225-3050
Participant code: 375491
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:
?? 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/16383/MinutesWsrmTC112905.htm
xx Moved to approve the 11/29
minutes, yy seconded.
?o 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,
- 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.
5.1
Reliable Request Response
Jacques posted the following contribution
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.
6
Future Meetings
At last meeting, TC agreed to decide on the next meeting at this
meeting.