[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] COmments on Doug contribution
Jacques, Comments below. I believe you have misinterpreted my intent which may mean the words in the specification remain unclear. Please suggest alternatives that maintain a clear separation between the "wire level" RMP exchanges (SOAP MEPs and the RM-Reply Patterns that bundle them) and the Producer / Consumer interactions (payload exchanges which might be described using WSDL and which involve the RM operations). thanx, doug On 11-Aug-04 01:30, Jacques Durand wrote: > Comments on Doug contribution (--08-07-drb-diff): > I only list below the points I have problems with - agree with all other > updates I am silent about... > The most controversial and far-reaching (beyond editorial) are the > changes in 2.5.2 and 2.5.3, see my last comment. > We need to have a once-for-all discussion on this... > > Regards > > Jacques > > > L352: This bullet is redundant with RM contracts that are defined > afterward. > Also, this kind of summarized requirement is risky: it is likely to > clash with more detailed requirements > coming later. (e.g. is it about "in-order" messages only? if yes, such > an arbitrarily scoped statement is condusing, and if applicable > > if not, it suggests that duplicates that are "valid" must be delivered > too for non-ordered groups. > I suggest to remove, or at minimum to change into: > " A receiving RMP MUST NOT invoke the Deliver operation on a message > that is either invalid or expired." This is one of those sentences that the TC as a whole word smithed and voted on. In fact, I did not change this bullet at all though it may have been accidentally deleted and later replaced as part of earlier edits. I believe this sentence is correct as worded and should remain unchanged. > Footnote 1 (p5): > As an RMP functions encompass those of a SOAP processor, I think it is > going to far to say that > "the Sending RMP would take no special action based on it (HTTP errors)". > I'd cautiously limit that statement to : > "The reliability features described here do not rely on the > interpretation of > non-SOAP responses." As described in my email about this contribution ("Contribution suggestions just uploaded"), these footnotes are for those reading the contribution only -- they explain particular deletions. None of this text should make it into our final document. > L391 and Footnote 2 (p6): The removed bullet was not questioning the > need for correlating messages for the > user side (Producer), but reminding of properties specific to this MEP, > that we assume will be supported along with this MEP by an RMP (even if > only needed in some particular cases). Correlation is actually assumed > in the SOAP 1.2 definition (by the "state machine" on the sender side). > So this removal was not really justified I think. Again, our specification makes no use of any correlation the underlying protocol may provide. I deleted this bullet because it does not matter for our protocol. In addition, as you note, the bullet adds nothing over our normative references to the SOAP specifications. We should not be attempting to summarize or re-define information available elsewhere. > L438-441: this small paragraph is unclear. I see an attempt to link > these reply patterns to the RMP operations: > my expectation was that we don't need to do so: these reply patterns can > be *defined* in terms of protocol only > (exchange patterns RMP to RMP). The fact that they may map to particular > usages of RMP ops, will be > conditioned by how these ops map to the SOAP MEPs, but that is specified > elsewhere and does not need encumber > the definition. No, I am attempting to distinguish the apparent patterns visible at the RMP and Producer / Consumer levels in the second sentence. The wording must be unclear if you are carrying forward the explicit mapping to the SOAP MEP from the RM-Reply Pattern in the first sentence to the explicit separation between the SOAP MEP and the use of RM operations in the second. Further, it is simply incorrect to link the RM operations with SOAP MEPs. Our abstract operations exist at a higher level than the RMP "wire level" interactions and are not defined in terms of SOAP. While that interface may be described using WSDL, SOAP and HTTP restrictions do not restrict it. I am attempting to tie SOAP MEPs to the RM-Reply Patterns and keep the RM-Reply Pattern connection to the RM operations separate. There is no link between the RM operations and the SOAP MEPs. > Section 2.5.2: I do not understand this very significant update: > it imposes that only SOAP One-way MEPs be used for Callbacks (both request, > and RM Reply) To me this is an unnecessary restriction: why do we need > it? (I don't recall the TC accepted this) > Even if in theory it seems more appropriate, when using SOAP > request-response, to always use Response Reply Pattern, a Callback or a > Poll could be used there also, with no harm for the RMP or pain for its > developer. We have discussed this issue at length and generally agreed to a number of things: (1) every request-response underlying protocol may be used in a one-way fashion, (2) the HTTP protocol with or without the explicit restrictions introduced in BP 1.0 is a fine example of this, (3) our HTTP binding describes an implementation of exactly the restrictions I describe more generally in 2.5.2, and (4) the HTTP binding MUST be an instantiation of rules defined elsewhere. If we do not change 2.5.2 as I did here, we will leave Section 6 announcing restrictions such as "the Receiving RMP MUST return a SOAP Fault" and "the Receiving RMP MUST NOT return a SOAP Fault" without justification. I have not introduced any text which requires use of the Response RM-Reply pattern when using a request-response underlying protocol. Again, HTTP is a fine example of a request-response underlying protocol that can be "profiled" to implement a SOAP one-way MEP. That is actually the general case. > (and deleted Table in 5.2 clearly acknowledged that, so far) > I would rather leave that decision to users. > In particular, restricting to use One-way for callback RM Replies seems > unwarranted: > as 4.4 suggests, RM Replies can be piggybacked on any business message, > and that could be a separate request-response going the other way. > Bundling of RM Replies works also for Callbacks (Section 6), and there > may be many reasons why someone may want to use this feature, e.g. a > callback RM Reply could be sent back for acknowledging many reliable > messages, some of them may be carried by request-response MEPs, some by > One-way MEPs (that may be determined by the operations these messages > may bind to, e.g. as determined by SOAP or WSDL bindings.) But all these > may be sent in the same group and be subject to the same RM policy. Some > Callback RM Replies could > > aslo come back before even the business response is sent back, on a SOAP > request-response. > I have same general concern for restrictions introduced in 2.5.3. Sorry, the rest of this does not make any sense to me. Perhaps I have answered your questions above? If you are again worried about Consumer payloads getting back when using other RM-Reply Patterns, that is easily implemented with small changes to our specification or as a restriction of our protocol. We could extend the restrictions on the first message described in the Response element (now applied to only the Response RM-Reply Pattern, see Section 4.4). That element could be *required* to identify the Reliable Message to which the message payload (or attachments) is a business response. We have not done that but nothing in the text presently prevents inclusion of Consumer payloads with RM-Reply publications when using any of the RM-Reply Patterns.