[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Preliminary Thursday minutes sent on behalf of Tom Rutt
|
-bob |
|
Bob Freund provided a new bridge number to allow us to dial
in at the meeting. Joe Chiusano - bah Review of Homework assignment statusIwasa produced draft .994: Document Description: This was updated for: DraftPublicReviewOutcomeforMinutes.htm with: 1.4, 2.2, 2.6, 3.17, 5.1, 6.1, 7.2, 7.3, 7.4, 7.5, 7.8, 7.11, 7.13, 8.2, 8.5, and editorial updates for examples
as described in a minutes on And here are some comments: 2.5 *This was already resolved at 0.993: 7.12 Schema in appendix *The latest schemas Needed. Action: Iwasa needs to make a new appendix, with the disclaimer for schema precedence (as in the schema text) and a URL pointing at the current schema on the WSRM server. 7.13 526: "nor to notify failure on the sender side" should be "nor to notify the RMP Sender of the failure". *Replaced "RMP Sender" with "Sending RMP" agreed 7.13 527: "it's" should be "its". Schemas: "it's" (in comment blocks) should be "its" *Schemas was not taken care of. Other items in 7.13 was implemented. Sunil has action item to apply comment 7.13 resolution to schema. Action on Jacques: incorporate his new Agreement section while doing the document restructureing. Draft resolution of CF public review commentsWe need to prepare a paper which rebuts the concerns of Chris Ferris, expressed in his presentation to the OASIS Symposium, and provides a counter argument as to the perceived problems with the WS-ReliableMessaging spec from Microsoft, IBM and partners. The following was provided by Tom Rutt as a starting point for resolving the CF public review comments: Cf1: Two schemas and namespaces are unnecessary for two soap versions. Agreed: Proposed change: remove the soap 1.2 schema, and change the following lines on the soap 1.1 schema: soap 1.1 schema has: to the folloing: " Cf2: Why are soap faults not used for RM-Fault? The SOAP Fault model was not used to report RM Faults is because: - SOAP Fault model doesn’t support batching of Faults which this protocol requires. - While it is not illegal to send a Soap Fault in an HTTP Request, it is unusual to send a Fault in a request message. Proposed change: none required Cf3: Not Acking until delivery to the application causes unnecessary delays? The definition of delivery in the specification is abstract, and allows implementation architectures using queues and other mechanisms not actually requiring the ultimate receiving application to participate in the acknowledgment procedure. Delivery can occur as soon as the Receiving RMP can ensure that the delivery contract associated with the request is satisfied (e.g., all prior messages in an ordered sequence have been received). In most cases delivery occurs immediately after receipt of the message. The initial contribution to the TC work had a protocol which returned an ack to the sender as soon as the message was received (assuming it is not expired). However, this behaviour admitted failure use cases where the sender would think the message was delivered, while a failure condition after this ack, admitted cases where the message could not be delivered (e.g., the receiving RMP has a processing failure while a received messages is being held waiting for a prior message in an ordered sequence). Also, the state machine was simplified significantly by sending the ack only when the receiving RMP delivers the message (e.g, makes it available to the next processing element in a chain by putting it in a queue). Proposed change: none required Cf4: Unclear if the spec can compose with WS-Addressing or WS-MD? An important consideration in design of the WS-Reliability protocol was to have it be composable with any other web services protocols which define the use of soap header elements. WS-Reliability defines elements to be sent in Soap headers . Our header elements only contain parameters essential for the operation of the WS-reliability protocol. For example, WS-reliability defines a reply to element for the sending Reliable Message Processor to convey a call back address for the Reliable messaging reply. This address is independent of any other reply mechanisms used for other protocols (e.g., WSDL response is not influenced by the WS-Reliability reply To parameter). The syntax for this element is URI, since that way of referencing a soap endpoint is independent of any specific adressing or message delivery specification. We want ws-reliability to compose with many other mechanisms. The WS-Reliable messaging protocol, since it relies on ws addressing From address as the callback destination, does not support a callback to a different endpoint than the from address. Proposed change: none required Cf5: Persistence model will not work on devices with volatile storage? WS Reliability does not explicitly prescribe persistence requirements. The persistence requirements (e.g., holding a received message in a buffer until all priors have been delivered in an ordered sequence; holding a list of integer ranges of sequence numbers which have been delivered, or faulted) are identical for WS-Reliability protocol and WS-ReliableMessaging protocol. A device with volatile storage (e.g, memory goes away when power goes away) can meet the requirements of the protocol as long as its storage remains in tact. Because messages are only acked when delivered, in cases where failure of the non-volatile storage results in a message not being delivered, the sending RMP will not receive an ack. The sending RMP can notify the producer of the message that the message is not assured to have been delivered. Proposed change: TC is checking if there is any mention of persistence remaining, which will be removed. Cf6: Mandatory Expiry time requires synchronization of clocks: The precision of the expiry time selected by the sending application needs to be selected to allow for normal skews in system clock. Although there may be some merit in designing a more robust mechanism to deal with excessive clock skews, the expiry time mechanisms used is consistent with other specifications, such as ebxml Messaging, ws lifecycle management. Propose change: under discussion by the WSRM TC. Cf7: There is unnecessary complexity in the spec, headers have unnecessary elements making them larger than necessary? The TC charter required the WSRM TC to produce a requirements document to determine features, required by members of the TC, to be met by the protocol. These requirements led, amongst other features, to the need for three RM reply patterns to cover the use cases identified in the requirements. The WS-Reliable messaging specification, from Microsoft IBM and partners, does not support all the use cases identified in the WS-Reliability requirements (e.g., it does not support polling for RM replies), thus its protocol may seem to be less complex. However, conformance claims can be made by an implementation to any valid subset of WS-Reliability features. A receiving RMP can return a notSupportedFeature rm-fault code in response to a request for features it cannot satisfy. Thus a WS-Reliability implementation needs only be as complex as required by the use cases it is designed to support. The cost of adding necessary indicators of features requested in request header elements is minimal in terms of header size and processing complexity. Proposed change: None required. Cf8 Spec does not state a Reciever MUST acknowledge all delivered messages with each acknowledgment indication. WS-reliability requires an ack to be sent for all delivered messages. It states “If a receiving RMP receives a message with AckRequested element, the receiver MUST send an Acknowledgment message even when the message is a duplicate, and if it has already been previously delivered.” Sending the complete ack history for a sequence along with every ack indication was deemed unnecessary for the WS-Reliability protocol. Ws-Reliability has a polling mechanism to allow the Sending RMP to request the acknowledgment status for all the messages sent within a Group. . Proposed change: TC is currently working on clarification wording which covers the polling case, where the ack is made available for a poll response (but not sent until the poll is received). Cf9 There is unnecessary implementation details in the spec. The spec has several, non-normative, implementation guidance notes. Proposed change: TC has agreed to move many of these non-normative implementation notes into an informative companion document. Paper in response to Chris Ferris Presentation at OASIS SymposiumThe TC agreed to prepare a paper to address the concerns express by Chris Ferris at the presentation, and to provide a balanced comparision, from our point of view, with the Microsoft IBM and partners WS-Reliable messaging specication. Points to be included in our comparison: Lack of polling support Why is “to” field needed for reliability. If both From and Reply to are present in the ws-addressing header, it is not clear where to send either the ack or the fault. They do not send any policy directives on the wire. Since there is no policy property defined for indicating duplicate elimination or other qos contracts, there is no specification on how this is accomplished. The spec does not address rm processing failures of any kind. Unclear what behaviour of NACK is when a fault is already sent for a particular message in a sequence. Poor support for groups with one message. Batching of faults is not supported. Sending an ack at time of receipt admits potential failure cases. Sending the entire ack history is not sufficient. (we should give one or more use cases which show their deficiency) Their spec is not clear with respect to a wsdl oneway operation how the destination for the ack is determined. The schema is not fully explained in the spec, and there appear to be inconsistencies Bob F took action to lead a team to provide an initial draft of this paper for review by the TC. Sunil and Jacques joined the team. FAQAgreed that we should come back to addressing the FAQ after we prepare the paper. No discussion at this meeting. Pete wenzel ActionDef of Reliable
Messaging Processor (RMP): A
module capable of processing and enforcing Reliable Messaging as described in
this specification.
With regard to the transmission of a message from one RMP to another, the
former will
be act in the role of “sender” and the latter in the role of “receiver”. Pete: Need to relate this definition to base terms which have a normative definition in the soap specification. We also have to relate this to the diagrams. Sometimes they are called nodes, which is a soap term. Is an RMP an entire soap node, or soap processor, or is it just a slice of a soap node. This impacts the interfaces the rmp must expose and use to communicate with other processing elements. Jacques: It could be a soap node, but does not have to be. It could be implemented as a Java handler, which extends a soap node. Pete: we need to give it a definition which is flexible enough to allow alternative implementations. Jacques: the definition of deliver was left abstract for this reason. It does not necessarily mean reaching the ultimate application. It could be another handler in a chain within a node. We agreed to change “application” to “producer” and “consumer” throughout the document. Fig 7 and fig 4 are not consistent. These figures should be updated to use the terms “producer” , consumer and Sending rmp and receiving rmp. Pete: is the consumer role only on the receiving rmp end? We need to formally define “producer’ and “consumer” in the spec. Action: Jacques will lead a team to ensure the terminology used in the spec is consistent with normative terms in the soap spec. Pete W will work with Jacques to provide a proposal to resolve this. 11-12: Planning for Future CD Balloting April 29: Iwasa posts all agreed edits in a new .995 editor’s draft. May 4 morning: Jacques posts a change barred .996 editor’s draft for review by TC (including a rough draft implementers guide holding non-normative text removed from .995 draft. May 4 evening - resolve all comments at TC meeting with editing instructions for editors. May 6 - Final Editors draft posted resolving all comments. May 10 – member editorial review comments due May 11 – TC votes approval of CD 1.0 ballot and vote to submit to OASIS at call May 14 – three letters from members on “using the spec” May 14 – Submit package to OASIS for OASIS Standard
Processing Sunil expressed concern that there is not enough time for member review of the final editor’s draft between May 7 and May 11. Bob: Jamie clarified that once it is submitted for OASIS review, no changes are allowed by the process (no edits at all). We are doing restructuring and may editorial text changes. We should have a proof reading Tom will schedule 2 hour Tuesday phone calls for the next four weeks 5:30PM to 7:30 PM EDT. 12: |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]