[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Detailed review of Section 2-2.5, 5.2 and related definitions
I just re-read section 2 and see a few questionable connections and wordings. I suspect we have a few minor technical issues lurking that relate to my "Summary of WS-Reliability 1.01* issues discussed over past week" email. What do you think? - 338-340: "Four operations (Submit, Deliver, Respond and Notify) are used to model the reliability contracts between an RMP and its users (Producer and Consumer components) as well as to relate these contracts to SOAP message exchange patterns used." It is the RM-Reply Patterns which relate to the SOAP MEPs used. The abstract operations correspond to something we have previously called the application-level WSDL. Unless WS-Reliability is considered a binding for the WSDL written at that level, the MEPs (certainly not SOAP MEPs) are not relevant. [minor technical?] - 359-360: "The submission to an RMP of a payload subject to a reliability agreement MUST be done via the Submit operation." Who must do what? This sounds like a requirement placed on the Consumer that is somewhat unenforceable and comes directly from the fact that our RMPs have an abstract interface involving only the four abstract operations. If this is attempting to make that abstract interface more clearly the *only* interface between the RMPs and their associated Consumer or Producer, we should make the comment straightforward. [minor technical] - 379-393: "SOAP One-way MEP:" & "SOAP Request-response MEP:" Is this not an attempt to replicate information already available in the SOAP 1.1, 1.2 or WSDL 1.1 specifications? I have not gone looking but this seems like it should be redundant. What can we refer to instead? I would prefer to simply make a reference and be clear that we are talking about these two terms as they apply to the wire-level messages exchanged between the Sending and Receiving RMP. [editorial or minor technical?] - 423-425: "For example, conformance of message exchanges with WS-I BP 1.0 requires the use of bindings (b1) and (b3) above, given the binding between SOAP MEPs and HTTP described in Section 6." What makes this sentence true? SOAP 1.1 and BP 1.0 or 1.1 do not say anything about two separate one-way MEPs and I see nothing else eliminating the (b2) case. [minor technical] - Section 2.4 On re-reading, this entire section implies that WSDL can only be written down to describe the application level (Producer to Consumer) interface. Since the need for this section arose out of my "Summary of WS-Reliability 1.01* issues discussed over past week" points, I do not think we have quite fixed the problem. I was recommending we avoid WSDL terminology entirely (except in Appendix B) or at least be very clear we are talking about WSDL the Consumer provides. [technical] - Section 2.4 This section also makes a more clear and inflexible link between the high-level abstract operations and the wire-level SOAP exchanges than we have had before. The terms should be introduced as a description of implementation flow which may be used to implement the RM-Reply Patterns. Reaching across abstraction levels in the current fashion just adds restrictions without adding value. [technical] - Section 2.5 Now that we have introduced the terms one-way and request-response, why not use them more clearly in this section? While 2.5.1 is quite explicit here, 2.5.2 and 2.5.3 are not. None of the sections refer to the defined bindings either. Binding (b1) corresponds to some of the exchanges in the Callback and Poll RM-Reply patterns (the original message for example). An so on. Lines 440-441, for example, say "...in a request of a SOAP Request-response MEP instance (or in the message of a SOAP One-way MEP).", this is general enough to say nothing. [editorial and minor technical] - 1360: "WS-I BP 1.0 prohibits sending a SOAP envelope in an HTTP response," This is not generally true but is true for WSDL one-way operations when they are directly mapped to SOAP exchanges over HTTP. In our case, the RM-Reply Patterns implement the exchanges described in the Producer / Consumer WSDL. SOAP messages are primarily an issue for the RMP implementation of those patterns. That is, this restriction does not reach down 3 levels! Even we wanted all levels in our stack to operate under the same restrictions (an inflexible approach), the generality of this statement would remain a problem. [minor technical] - 1364-1367: "While this specification doesn’t prohibit using the Callback or Poll RM-Reply Patterns to receive acknowledgments or faults for a Request-response operation, it encourages the use of the Response RM-Reply Pattern for such operations: the acknowledgment or the fault can be sent on the response itself, thus saving round trips." We encourage something that (apparently) does not support exchanges with no consumer payload? This continues to make no sense. If it means something to someone, it probably should be earlier in the specification in any case. [minor technical] I also see a very minor editorial issue here: We should say "does not"... [editorial] - 276-278: "For example, in one specific implementation choice, the Receiving RMP places the payload into a queue. This queue may represent the Consumer." I probably restored this sentence in the Deliver definition. It is now redundant with text in section 2.2. Suggest we remove it. [editorial] - 347: "The separation assumed here between Producer and Consumer and their associated RMP do..." This is a minor typographic error I just noticed. Should probably be "separations" to make the sentence consistent. [editorial] - 361-362: "The delivery of a Reliable Message MUST be done via the invocation of the Deliver operation." I think this is redundant with the following sentence (TC approved words). [editorial] - Section 5.2 In general, this section seems redundant with material now in Section 2. Why is it here? What does it add except confusion? [possibly editorial?] thanx, doug
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]