Re: [wsrm] COmments on Doug contribution

[Doug Bunting <Doug.Bunting@Sun.COM>]

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.