Re: Who Faulted (was RE: Proposed rewrite of Part 1, section 2 (l ong) )

I am reminded of the children's book by P.D. Eastman
"Are You My Mother?":)

I agree with Noah's points here, but I think that we
may be off the track.

The issues at stake are a) nomenclature
and b) guidance. While I agree that we (currently) have nothing
to say about what URI a node chooses to place in
the value of faultactor, the name itself is misleading
and its presence is somewhat puzzling. Unless there is
a defined purpose and usage for this element, its use
will likely be non-interoperable.

If the Fault is generated as a result of processing the
Body, then clearly, the "actor" is the implied "default
actor" or the "ultimate recipient" which is unnamed,
at least from the SOAP perspective.

Should the value of faultactor be empty if the Fault
arises from the processing of the Body? I think not!

If, as Noah suggests, the Fault is generated because
of issues in the Header (say a mU Fault(s)), and there
are more than one blocks which were not understood, and
each had a separate actor/role, which one does the SOAP
node use for faultactor? And why? Should the node select
one randomly?

Consider then a SOAP message path with three nodes(A, B, C). Which
of the ".../next"'s encountered/generated the fault if
the Fault was say an mU Fault on a header block targeted
at the actor/role of ".../next"? If B added a mU header
block targetted at the actor/role of ".../next", the
sender A may not be aware of that fact, and the Fault
would be relatively meaningless in any context A might have.

Consider further the case where A *does* include a mU header
block foo, targetted at the ".../next" actor, but which
has semantics that the receiving intermediary SOAP node (B)
processes that header block and then adds an equivalent
block also targetted at ".../next" which is then processed
at C which throws an mU Fault. Now A has even less information
on which to judge which node needs the upgrade for handling
the "foo" module. It might incorrectly infer that B threw
the fault.

Clearly, I don't think that this usage, while valid according
to the SOAP spec, is very useful. Clearly, we have a different
intent/meaning for faultactor than we do for actor/role.

If the intent (as I understand from 4.4.3) is to identify the
source node of the Fault, then it would be my recommendation
that the element be renamed so as to infer that semantic
intent,. e.g. faultnode. Eliminate any reference in 4.4.3
that mentions actor/role as the intent is clearly (IMO)
quite orthogonal to actor/role.

Cheers,

Chris
noah_mendelsohn@us.ibm.com wrote:

> I generally agree with Stuart's sentiments in this thread. 
> 
> Regarding node names vs. role names : first of all, I think we've been 
> clear that role names can be chosen to identify a specific node, or to 
> identify some more abstract purpose (next, cachemanagers, etc.)   I think 
> Jean Jacques is right that 4.4.3 needs some cleanup, but I don't think the 
> notion of role name is broken, and I don't think we should be in the 
> business of prescribing how many URI's might be used to identify a node (I 
> believe the web architecture is clear that the same resource can easily 
> have multiple URIs, none of which is necessarily preferred over others.) 
> So, I think none of this is broken in the current spec, except for the 
> need to clean up 4.4.3.
> 
> Jean Jacques suggests:
> 
> 
>>>I would be tempted to say that the faultactor 
>>>attribute really ought to identify not just the
>>>node that faulted (coarse-grained), but the exact 
>>>role in which that node operated (fine-grained).
>>>
> 
> I respectfully disagree with the notion that a node is acting in a single 
> role when doing any particular activity.  It is certainly the case that it 
> acts in a non-empty set of roles, and that each header identifies exactly 
> one such role as an actor.  On the other hand, it's easy to imagine 
> situations in which processing is triggered by a combination of headers. 
> It may be the combination itself that causes a problem, or it may be that 
> processing triggered by the combination causes a fault.  Let's imagine an 
> envelope with a header addressed to actor "TransactionManager" that says 
> "run as transaction" and contains another header targeted to "next" that 
> does some processing.  During that processing, an error occurs that 
> results from some interaction between the transaction header and the 
> processing for the header that is labeled "next".  I think its very 
> reasonable to ask the node to identify itself with a URI, and I don't 
> think we should say anything about what that URI is.  If the node chooses 
> a URI that matches a role, so be it.  If it chooses a role that matches 
> one used by the transport bindings, fine too, or it can use anything else. 
>  Specifications for applications of or deployments of SOAP might well 
> mandate conventions for the nature of such URI's, but I don't think we 
> should.
> 
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
> 
> 
> 
>

Received on Friday, 1 February 2002 08:08:42 UTC