Subject: Kicking off the discussion of Proposed New work items for WSRM TC
Date: Thu, 26 Jan 2006 19:25:03 -0500
On Tuesday's call (1/24/06), Tom asked Jacques and I to initiate an email exchange on the 2 proposed new work items identified in the Fujitsu contribution that was emailed to the list. That is the purpose of this email.
DISCLAIMER: NEC Corp does not take a position regarding these work items. I am only attempting to stimulate discussion and suggest alternatives for dealing with them. If sufficient email exchanges ensue, we will be closer to reaching a consensus by the next WS-RM TC call (2/21/06).
Jacques introduced these two work items on the Jan 24th call and we discussed them without reaching any conclusions. We did not discuss his detailed contribution of the Reliability of Response message, as time ran out before we could even reach agreement on whether we should do that work or not in WS-RM TC.
Here is my attempt to shed light on the two proposed work items:
1. Reliability of Response message (see companion Fujitsu contribution which provides details and summarizes what has been discussed to date on this issue). The proposed work item is intended to be a clarification of the text that already exists in our WS-Reliability 1.1 spec. There is some tie in between this proposed project and the Delivery Assurance proposal (see below), as there is an implicit notion of QoS/DA associated with a reliable response. We propose to unambiguously specify what that means. This document tries to set the requirements and define what it means to have reliability of the response message.
-->If we agree this work is needed, then it would be folded into an updated WS-Reliability (v1.2) spec. You could consider that to be an enhancement or just a clarification of the spec.
2. Standard Representation of Delivery Assurance (DA). The idea is to develop a "service definition" for DA in the context of reliable messaging QoS. The resulting document could be used with any Reliable Messaging protocol. So, it is NOT an enhancement of WS-Reliability or would it necessarily require any changes in our spec. The only potential impact on WS-Reliability might be to separate the DA description from the underlying WS-Reliability protocol spec (presumably this would mean deleting text from WS-R and placing reworded text in the proposed DA document.)
Here are a few related questions/issues on this topic, which were raised during Tuesday's call:
- How close is an assurance to a guarantee?
- Do we need the application ack of the receipt of the message?
- What addition capability can DA accomplish and what benefit(s) can it provide to the Application layer above?
- Is it the sender side's business about how the application on the receiving side is structured?
- What expectations can be derived from this?
- In our spec, DA is determined by the sender, but the driver is actually the side that produces the query and obtains a reliable response. Is it correct to think that the sender should always be in the "drivers seat?"
- What are the specific things that users of our spec need and do not have with our current spec? Don't know what number that should be? What are the specific end user requirements for WS-R?
- How does the TC find out the needs of its user community?
- Do our users desire the feature of being able to select different types of DA?
- How many users would really care about the additional delay of holding a message and not delivering it to an application (because it is out of sequence)
- As this proposed DA document would apply equally to WS-Reliability and WS-RX, should the work be done in our TC or a new TC?
- Should we be concerned about what users of the spec WS-RX want? (We don't know how it is being deployed).
Alternatives for the disposition of the proposed DA work items:
1. Do the work in the WS-RX TC (may require a change in our charter?)
2. Form a new TC to do the work (how many companies would commit to this?)
3. Include some notion of DA/QoS if we agree to update the WS-Reliability spec to clarify a reliable response.
3. Do not do this work at all in any TC.
Comments and suggestions would help us to better resolve these issues prior to the next call.
Best regards,
alan
Alan Weissberger
1 408 863 6042 voice
1 408 863 6099 fax