OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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 [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.

- 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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]