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: 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?]

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

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

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

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

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

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

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

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

- 276-278: "For example, in one specific implementation choice, the 
Receiving RMP places the payload into a queue. This queue may represent the 

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

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


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