Re: [wsrm] about review of Section 2-2.5, 5.2

["iwasa" <kiwasa@jp.fujitsu.com>]

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
>
>
>