[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Summary of WS-Reliability 1.01* issues discussed over past week
The following is intended to help get everyone caught up. Most of this derives from the abstract model in our specification, resulting in a number of contradictions between it and the rest of the document, underscoring a few over-general restrictions or indicating some under-specified concerns. While some of the issues below could be considered editorial, the bulk are at least minor technical concerns. When reading the following, it is very important to remember the distinction between the capabilities the WS-Reliability protocol provides to the producer and consumer and how that protocol maps to use of an underlying protocol. Producer / consumer interactions occur using WS-Reliability and WS-Reliability uses SOAP messaging (our underlying protocol). The RMP always has complete control over the bits on the wire though the producer and consumer may provide the bulk of the message content in a "pass through" fashion. The example "solutions" are provided primarily to make the issues clear. While some of these approaches may resolve the issues, we must come to a common understanding of the problems before working on solving them. 1) The existing descriptions of the callback and poll RM-Reply patterns assume the underlying protocol supports request-response SOAP interactions but do not explain what goes into the underlying response of the separate message exchanges. In detail, the response and synchronous RM-Reply patterns may be used only with an underlying protocol that supports request-response (a less general restriction than currently specified). For the callback and asynchronous poll RM-Reply patterns, we are using only one-way messaging; though the underlying protocol might support request-response, we should rely on the SOAP binding to describe or profile how the underlying response is used (or ignored). For example, we might clarify that these RM-Reply patterns involve two separate one-way SOAP message exchanges (callback), three separate one-way message exchanges (asynchronous poll) or a one-way followed by a request-response exchange (synchronous poll). Such a clarification might also address part of (2) below -- though at the cost of some generality. 1a) The "non-essential assumption" that the underlying protocol supports request-response SOAP interactions, stated in section 2.1, should be removed. This is no longer a general assumption but something specific to two of our four RM-Reply pattern options. 1b) The HTTP Binding should be an instance of the general semantics described in the main body of the specification and not extend those semantics. The current section provides examples of semantics not described elsewhere. After resolving the areas left under-specified or over-generalized in the rest of the document, we must recheck section 6 for conflicts with these semantics. In addition, any transfer protocol responses that may be unclear because we are using a request-response underlying protocol in a one-way fashion should be described by reference to the appropriate SOAP over HTTP binding. 2) Section 5.2 is completely about the producer / consumer interactions though some of its text has been applied to the RMP use of an underlying protocol. The matrix in section 5.2 states that all RM-Reply patterns may be used with consumer-generated payload(s) or application responses on the receiving RMP side. However, the callback and poll RM-Reply patterns provide multiple opportunities to return payload information (as they are currently described, see (1) above) and the specification does not describe which option is recommended. Our new Respond operation (possibly restricted to specific RM-Reply pattern choices) must be mapped to the underlying protocol at least as far as timing is concerned. We may also decide to further restrict when the consumer may invoke the Respond operation. 2a) The sentence "However, an RMP is not requried to disinguish WSDL operation types." [please note new spelling errors] was introduced in a recent edit to section 5.2, enshrining an assumption a few of the TC had previously made. This assumption contradicts the complete control an RMP has over the bits on the wire. The consumer may or may not provide payload information (the consumer interface may be described using either a request-response or a one-way operation type). Even if the receiving RMP is only passing the information through, it must be aware of when to wait for the consumer to invoke the Respond operation. This sentence should be removed. 2b) The one-way consumer interface and Response RM-Reply pattern is the most direct combination to reliably deliver one-way messages from a producer "hidden" behind a firewall. The matrix in section 5.2 should not disallow this combination. While synchronous polling at least works, it always requires an additional round trip. 2c) The matrix in section 5.2 also was the first to introduce the idea that the consumer could provide information intended for the producer. We needed to extend the abstract model to introduce this earlier and avoid a contradiction between the matrix and the model. I believe this issue has become editorial as we discuss the details of the edits necessary. 2d) When using the Response RM-Reply pattern, the immediate underlying response may be lost and the sending RMP may query using a Poll request. Should the response to such a "spontaneous" Poll indicate which referenced messages included consumer payloads in the earlier response? The sending RMP might "just know" a consumer payload may be available from information the consumer provides (WSDL, say) or some other means; an indication of a consumer payload in the Poll response informs the sending RMP directly. The sending RMP can already decide when a resend might be necessary and any indications the receiving RMP provides would be a new extension to the WS-Reliability protocol. Such an extension would, primarily, reduce the size of the known subset requiring resends since any a priori information would indicate only that a consumer payload had been possible. 3) The description of duplicate elimination in section 3.2.2 does not describe the content of either the immediate underlying protocol response nor an RM-Reply that may be sent later (in the callback or poll RM-Reply cases). In particular, whether or not consumer payloads from the response sent the first time (in the case when the earlier response had been lost) may be returned during this iteration is left unspecified. As Sunil has stated, some have implementation issues with caching payloads in the receiving RMP though this is the most appropriate way to handle the duplicate message. We might thus avoid a new requirement but concentrate on ensuring caching is allowed. 3a) Sunil mentioned in a private email that no RM-Reply pattern at all is used unless an acknowledgement was requested. I have not searched but am pretty sure we have not described RM fault semantics, duplicate elimination nor consumer payloads in this situation. For example, will the callback be invoked or the poll include any information about successfully delivered messages when AckRequested did not appear in the original message? I suspect we moved the ReplyPattern element out from under the AckRequested to allow more generality here but the existing text implies an RM-Reply is always publicized. 4) The RM Fault processing model described in section 4.5 previously attempted to cover responses to duplicate messages though the reader was not directed here from 3.2.2 "Duplicate Elimination". I believe we have agreed not to lump faulting and responding to a duplicate message together in the document and have addressed the editorial issues in section 4.5. 4a) Sunil has outlined a few issues with including a SOAP fault when returning an RM fault. If I remember correctly, the original reason for this addition was avoiding an empty SOAP Body when the sending RMP expected a consumer payload. If we accept all of the restrictions and clarifications mentioned above (in (1) especially), the problem will be limited to use of the Response RM-Reply pattern (request-response underlying protocol utilization) with a consumer response expected. The SOAP Fault would cause the underlying protocol response to match the signature expected in that case but may cause interoperability problems in other cases. Sunil would like to avoid the inherent redundancy of a message containing both SOAP and RM faults. He also points out that "send a SOAP fault" is not specific enough. 5) The specification is generally vague about the meaning of "application-level" and talks about WSDL primarily as describing the producer / consumer interaction without making this distinction clear. In some cases, WSDL operation or MEP types are applied at all levels. As a relatively editorial matter, we must clarify distinctions between exchanges controlled by the RMP processing ("underlying protocol" or SOAP message exchanges) and how the RM-Reply patterns map to those exchanges and the producer / consumer interface (sometimes described using consumer-provided WSDL). In effect, the producer and consumer sit on top of an RMP that is (abstractly) implemented using an underlying SOAP processor. That SOAP processor provides the one-way or request-response message deliveries used for the RM-Reply patterns. The RMPs effectively provide another, higher quality of service, WSDL binding that the producer and consumer use to interact. We probably do not need to include the SOAP processor explicitly in our model but we do need to be clear throughout or document what level is discussed. Primarily, section 5.2 will be the main place in which the producer / consumer interface come to the fore. And, no, this is not as large a change as it seems.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]