Re: Comments - WSDL 2.0 Message Exchange Patterns

Other comment on part two; it refers to {label} properties, whereas 
part one uses {message label}; should these be the same?

Cheers,


On Jun 16, 2004, at 8:49 AM, Amelia A Lewis wrote:

> On Tue, 15 Jun 2004 15:35:53 -0700
> Mark Nottingham <mark.nottingham@bea.com> wrote:
>
>> Please find below my comments on the WSDL 2.0 Message Exchange 
>> Patterns
>> document [1] (dated 2004/02/24).
>>
>> * The draft uses "patterns" and "WSDL patterns" often; suggest either
>> normalising to "WSDL Message Exchange Patterns" or beginning the
>> introduction with "Web Services Description Language (WSDL) message
>> exchange patterns (hereafter, 'patterns')..."
>
> I'd like to take the latter suggestion as an editorial, if that suits
> others.  It means fewer changes, and qualifies as editorial, I think.
>
>> * It might be advisable to differentiate the MEPs described here from
>> the messages in underlying protocols (to use SOAP terminology); 
>> perhaps
>> "Interface Message Exchange Patterns"? (I don't feel strongly about
>> this, just a suggestion)
>
> See archives of the task force for discussion of this.  I'm loath to
> reopen it (David Booth, can you comment?).
>
>> * A short, formal definition of what a Fault is, in WSDL terms, may be
>> useful (not necessarily in this document, but somewhere).
>
> Hmm.  Probably part one, where the syntax is.  Relate that syntax to 
> the
> semantic of application fault.
>
>> * Section 2 uses "generation" in reference to Faults, which seems to
>> have a different meaning than in SOAP. When A SOAP Fault is generated,
>> it is not necessarily transmitted on the wire; here, the implication
>> seems to be that it is. Suggest using "Fault transmission," "Fault
>> delivery," or "Fault destination" throughout instead. This would make
>
> Err.  Not fault destination.  "Transmission" seems sorta okay.  It's
> really about generation, though, and the *attempt* to transmit, whereas
> "transmission" implies that it actually gets successfully sent.
>
> The rulesets specify: when faults may occur, how the destination for 
> the
> fault is chosen (replace a message, return the fault to the source of 
> the
> message that triggered it).  Fault creation and targeting ruleset?
> Cumbersome.
>
>> the first sentences in the section something like: "WSDL patterns
>> specify the destination and transmission of any Faults generated in a
>> message exchange using standard rules.
>
> Awkward.  There's an implication that external rules govern the
> generation.  Which may be true in the sense that they govern what 
> *causes*
> a fault, but is not true in the sense that faults may only "occur" at
> certain points in any given exchange (a fault is never the first 
> message
> in an exchange, as an example).
>
>> The most common such rules are
>> defined here and referenced by patterns later in this document. A
>> Fault, regardless of the rule in effect, terminates the message
>> exchange it occurs in."
>>
>> * Can the destination or occurrence of a Fault be overridden
>> dynamically?
>
> The specification is silent on this issue.
>
> Since it is not forbidden, it would be trivial to add a 
> fault-to-address
> feature/property, and state in the specification of the feature that 
> the
> property MAY (if it is optional) or MUST (if it is required) be the 
> target
> for faults triggered by the message.
>
>> E.g., can I specify a SOAP header that says "send any
>> faults over there" or "keep that fault to yourself"?) If so, the
>> mechanisms in section 2 should be couched as "Default Fault Generation
>> Rules," or "Default Fault Transmission Rules", with appropriate
>> explanatory text, if the previous suggestion is accepted.
>
> Does "default" carry the implication that they are used unless 
> something
> else is specified?  I'm concerned that the word would confuse readers.
> Would it work to mention that features or bindings might override the
> ruleset in some fashion?
>
> Amy!
> (responding primarily as part two ed)
> -- 
> Amelia A. Lewis
> Senior Architect
> TIBCO/Extensibility, Inc.
> alewis@tibco.com
>
>

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Received on Friday, 18 June 2004 16:12:19 UTC