Re: proposal for faults

Sanjiva Weerawarana wrote:
> So, it seems to me that the syntax proposal I made to Jeffrey
> is still acceptable, but the difference is that the value of
> operation/fault/@messageReference would resolve to any message
> ref in the pattern as there is nothing called a special fault 
> message reference in the pattern. Then, in combination with 
> the fault rule of the pattern, that unambigiously states what
> the fault is and who's sending it to who. 
> 
> Amy/Jeffrey: Do you guys agree? If so I will send a summarized
> proposal to try to get closure on this as I doubt everyone 
> followed this thread carefully. 

I'm still mulling over the change from infault/outfault to fault.

Here's the first example that Amy sent, the one that uses fault-replaces-message:

<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="M2" details="F3"/>
   </operation>
</interface>

And here's the same example with infault/outfault:

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

Here's the second example (with message-triggers-fault):
(by the way, I changed the pattern URI to be different
from the previous one)

<interface name="foo">
   <operation name="this-is-irrelevant"
              pattern="http://mypatterns.org/pattern2">
     <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>

And the equivalent with infault/outfault:

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

My observation then is that the versions with infault/outfault
are much easier to understand: you can tell at a glance in
which direction the faults are flowing. Using just "fault"
everywhere obfuscates this important piece of information.

Roberto

Received on Thursday, 2 October 2003 20:57:54 UTC