[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] about review of Section 2-2.5, 5.2
My comments identified by <iwasa> are inline: ----- Original Message ----- From: "Jacques Durand" <JDurand@us.fujitsu.com> To: "WSRM (E-mail)" <wsrm@lists.oasis-open.org> Sent: Wednesday, August 04, 2004 4:22 PM Subject: [wsrm] about review of Section 2-2.5, 5.2 > inline <JD> > > Doug wrote: > > From: Doug Bunting [Doug.Bunting@sun.com] > Sent: Tuesday, August 03, 2004 2:36 PM > To: wsrm > Subject: [wsrm] 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?] > > <JD> We can remove the part "as well as to relate....used." > The idea was, the SOAP MEP that is used is likely to be determined first by > which RMP operation is used to send a message, rather than by which RM Reply > Pattern is requested. But after all that is implementation choice. > (the way input and/or output messages of a Consumer WSDL operation bind to > particular RMP operations in more prescriptive, in our spec.) > > > - 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] > > <JD> right. We only define a reliability contract for what is submitted via > Submit, and that > is sufficient. Anything submitted any other way simply falls out of the > contract. Let us remove. > Now, I would also remove "A Sending RMP MUST support the Submit > operation.": after having made the > case that these RMP ops are abstract and that id does not matter who > implements them, this MUST is superfluous, implementish (try to coin a term > here..) > and associated with a rather vague "support" verb. All what matters, > is to specify whether the RMP is required to > invoke the abstract op or not. (and we say so for Notify and > Deliver, in "Terminology" section, although you may have forgotten > to mention it for Deliver when doing the merge). Along this logic, I > would also remove the second bullet of this list (L361), > as it does not say anything new. Plus, the "MUST invoke the Deliver > operation for every valid, in-order and non-expired message it receives" > seems > a dangerous summary of (and redundant with) a more complex logic > that is actually the matter of this spec. > > > > - 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?] > > <JD> I have not found a precise def of SOAP One-way MEP anywhere, and > would be glad to refer to an existing one if we find one. So here note that > I do not > go as far as proposing a definition, but rather lists some relevant > properties we assume for such an MEP. > As for SOAP Request-response MEP, it is defined in SOAP 1.2 > but we need make the case that this definition also makes sense when using > SOAP 1.1 too. > (SOAP 1.1 refers to allowing using MEPs but does not define them). > So this section does not "define" (or re-define), but rather lists > properties assumed for such MEPs, > the use of which we want to consider (for both SOAP 1.1 and SOAP 1.2) in > this spec. > If there is another way for us to introduce SOAP MEPs (which allow us to > make abstraction > of the underlying protocol) I am for it. > > > - 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] > > <JD> because BP 1.0 requires binding a WSDL request-response operation > to an HTTP POST request-response, and the SOAP binding adopted is also the > one described in SOAP 1.1 > assuming a SOAP response on the HTTP response, it follows that the > properties we expect from a SOAP request-response MEP > are satisfied, (and the properties we describe for a SOAP One-way are not). > > > > - 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] > > <JD> right, we are talking of the case where WSDL describes messages that > are passed to Consumer via Deliver (input messages) and sent from COnsumer > via Respond. > Probably that should be presented as one use case of WSDL + RMP (when > sending reliable messages > to a Web service.) We might push that back to the end, but on the other hand > it > may be useful for reader to have a concrete example on how these RMP > operations can be used > in a Web services context, in which after all WSDL plays a significant > role... > > - 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] > > <JD> section 2.4.2 does not play a major role, and could take a less > prominent place. > We could even remove it if others think it more confusing than helpful. > I think a valuable statement behind it is that the context of use (e.g. BP > 1.0) may constrain > the SOAP MEP being used, even prior to what RM Reply Pattern you want to use > in your > reliable message (and that in turn will restrict what RM Reply Pattern you > can use, as stated in 5.2., > given the COnsumer WSDL-to-RMP link ) This rationale was hidden in 5.2. > > > - 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] > > <JD> Lines 440-441 say at least that it is NOT sent in the response of a > SOAP request-response MEP... > These definitions are expressed here only in terms of wire-level > exchange patterns, and do not depend on RMP operations. > Of course there will be an induced dependency with RMP operations, but the > definition of these Reply Patterns > does not have to address that: these Reply Patterns can be defined even > without assuming > RMP operations. > So these sections define a scope of applicability of each RM Reply Pattern, > in terms of > what usage of SOAP MEPs is expected. > > > - 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. > > <JD> Well, this statement is associated with "**" which refers to One-way > WSDL. > > 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! > > <JD> I will try to address the remaining later - from a quick look, I have > no strong disagreement > with statements below. > (but need to get some sleep now...). > > > ---------------- > > 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] <iwasa> I propose to remove the sentence (line number 1339-1342 in WD1.08). Because we have enough description in "2.5.1 Response RM-Reply Pattern" and the first portion of "4.3 PollRequest Element". I believe those description are enough. </iwasa> > > I also see a very minor editorial issue here: We should say "does not"... > [editorial] <iwasa> This would be resolved with the above proposal. </iwasa> > > - 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] <iwasa> Agree. </iwasa> > > - 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] <iwasa> I believe no one has problem to fix this typo. </iwasa> > > - 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] <iwasa> I agree to remove this sentence. This is redundant. </iwasa> > > - 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?] <iwasa> I personaly don't have objection to remove the sentence. Or it could be merged with section 2 if someone prefers to do so. I can live with either way. I propose to remove the section 5.2, if no one made objection. Thanks, Iwasa </iwasa> > > thanx, > doug > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]