Re: proposal for faults

Oh, no!

On Thu, 02 Oct 2003 22:54:34 +0600
Sanjiva Weerawarana <sanjiva@watson.ibm.com> wrote:
> "Jeffrey Schlimmer" <jeffsch@windows.microsoft.com> writes:
> > 
> > Would fault/messageReference resolve to
> > interface/operation/{input,output}? Or would it resolve to something
> > defined by interface/@pattern?
> 
> I'm confused .. let me try a full syntax example:
> 
> <interface name="foo">
>   <operation name="this-is-irrelevant"
>              pattern="http://mypatterns.org/pattern1">
>     <input messageReference="M1" headers=".." body=".."/>
>     <input messageReference="M2" body=".."/>
>     <output messageReference="M3" body=".."/>
>     <output messageReference="M4" body=".."/>
>     <fault messageReference="F1" details=".."/>
>     <fault messageReference="F2" details=".."/>
>     <fault messageReference="F3" details=".."/>
>   </operation>
> </interface>
> 
> So, presumably the pattern @ http://../pattern1 has messages called 
> M1..M4 and fault messages called F1..F3 that fly back or forth. The
> value of operation/fault/@messageReference will be on of the names
> F1..F3 given by the pattern definition and therefore the pattern
> definition would indicate which way the message is flow (in or out). 

I can't support this!  It would force the definition of faults back into
the patterns, rather than using the fault rulesets.  Here's a simple
counterexample of what I thought we were discussing:

<interface name="foo">
  <operation name="this-is-irrelevant"
             pattern="http://mypatterns.org/pattern1">
    <input messageReference="M1" headers=".." body=".."/>
    <output messageReference="M2" body=".."/>
    <fault messageReference="M2" details="F1"/>
    <fault messageReference="M2" details="F2"/>
    <fault messageReference="M4" details="F3"/>
  </operation>
</interface>

That's an input-output pattern, and it uses fault-replaces-message. 
Here's the same, with message-triggers-fault:

<interface name="foo">
  <operation name="this-is-irrelevant"
             pattern="http://mypatterns.org/pattern1">
    <input messageReference="M1" headers=".." body=".."/>
    <output messageReference="M2" body=".."/>
    <fault messageReference="M1" details="F1"/>
    <fault messageReference="M1" details="F2"/>
    <fault messageReference="M2" details="F1"/>
    <fault messageReference="M2" details="F3"/>
  </operation>
</interface>

In the first pattern, the only place a fault can occur is replacing
message M2.  Note that this could be minimized, in the same way that
input/@messageReference and output/@messageReference can be minimized
(omitted, that is).  If there's only one thing it can be, then it
becomes optional.

In the second pattern, a fault may be triggered by either message.  The
fault/@messageReference is therefore required (although
input/@messageReference and output/@messageReference could be omitted). 
In the second example, fault F1 may be sent in either direction; F2 can
only be triggered by message M1, and F3 can only be triggered by M2.

I *really* don't want to fall back into the place where we have to
define every possible location in which a fault occurs, which the
proposal I'm responding to seems to require.

> Thus, whether a fault is inbound or outbound is fully determined 
> based on the messageReference the fault element indicates. 

Still true, largely.  Actually, in the examples I provide above,
direction is determined by @messageReference + the fault ruleset used by
the pattern.  The relationship is probably slightly more obvious for
fault-replaces-message.  An interesting variation might be: use
attributes @replaces="messageReference" or
@triggeredBy="messageReference".

> Now, can you re-ask your question please? I didn't grok it at all.

Amy!
(offering water ...)
-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Thursday, 2 October 2003 13:17:29 UTC