RE: are fault-replaces-message (FRM) and message-triggers-fault ( MTF) equivalent

Hi Amy, Hi Sanjiva,

Thanks, I see the difference now. 

A related question: What's the semantic of multiple faults in an operation (as in Sanjiva's example)? With WSDL1.1, I believe having multiple faults under an operation means they are alternatives. But with the introduction of multi-in and multi-outs, it might be becoming confusing now. The meaning seems maybe different based on the pattern. (e.g, for an in-out pattern, it may still mean alternatives, but for in-multi-out, it's unclear) 

BTW, I just finished reading the part 2 spec and my impression is that this difference is not efficiently expressed, especially since the scenario you described below is not included in the spec. Would it be nicer for the readers if we can add your example to the spec?

Best Regards,
Kevin
 

-----Original Message-----
From: Amelia A. Lewis [mailto:alewis@tibco.com] 
Sent: Monday, Nov 03, 2003 07:28 AM
To: Sanjiva Weerawarana
Cc: www-ws-desc@w3.org
Subject: Re: are fault-replaces-message (FRM) and message-triggers-fault (MTF) equivalent



-1.  Sorry.  See below.

On Sun, 02 Nov 2003 16:07:37 +0600
Sanjiva Weerawarana <sanjiva@watson.ibm.com> wrote:
> We currently have two fault patterns:
> 
> - FRM which can be used *after* the first message (since it doesn't
>   make sense to start a MEP with a fault :-))
> - MTF which can be associated with the first message even, but of
>   course the fault follows the message since its the occurrence
>   of the mesasage which triggers the fault.
> 
> Now, can we not just stick to MTF? FRM seems like just a special
> case when the fault is associated with the first message but
> defined with MTF.  

Not exactly.  MTF specifies that the node faulting must try to return
the fault to the sender of the message.  FRM specifies that the node
faulting must try to send the node to the designated recipient of the
message it is supposed to transmit.

This means, for instance, in the commonly-discussed case of a three-way
req/resp (node1 in-> service out-> node2), that the target for the fault
generated by the service differs depending upon the model used.  For
FRM: node2.  For MTF: node1.  This has security implications.

> With FRM, we'd specify a simple in-out scenario with faults
> as follows:
>     <operation name='foo'>
>         <input messageReference='A' body='x:e1'/>
>         <output messageReference='B' body='x:e2'/>
>         <outfault messageReference='B' details='f:f1'/>
>         <outfault messageReference='B' details='f:f2'/>
>     </operation>
> 
> If we switch the in-out to use MTF instead, this would look like
> this:
>     <operation name='foo'>
>         <input messageReference='A' body='x:e1'/>
>         <output messageReference='B' body='x:e2'/>
>         <outfault messageReference='A' details='f:f1'/>
>         <outfault messageReference='A' details='f:f2'/>
>     </operation>
> 
> The only difference is the value of outfault/@messageReference.
> 
> I can't think of a case where an FRM scenario couldn't be expressed
> using MTF thus.

in-only, out-only.  Using MTF, you get faulting.  Using FRM, you get
WSDL 1.1 style no-fault operations.

> So, shall we drop FRM and stick to MTF??

*laugh*  Last time, the proposal was to drop MTF and use only FRM.  I
think both are necessary, honestly.  Although I tend to agree that MTF
is more robust.

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

Received on Thursday, 6 November 2003 19:22:50 UTC