about review of Section 2-2.5, 5.2

Title: about review of Section 2-2.5, 5.2 

inline <JD>

Doug wrote:

From: Doug Bunting []

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]

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