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

> 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.

It was not my intend to suggest that the notion of role is broken. I think
section 2 is fine as is (modulo the ed's proposed rewrite), and I generally
agree with your view above. My concern is primarily on section 4.4.3 and the
"faultactor" attribute. Initially, I thought this attribute's name and
description were simply inconsistent with section 2; "faultrole" might have
been a better name. What you wrote below leads me to think that we have a
deeper problem. If indeed the current "faultactor" attribute is allowed to
represent "a role that matches one used by the transport binding", or
"anything else", then I think the name of "faultactor" is indeed misleading.
Or are you really saying that the "actor" attribute itself may carry any of
these values as well --which IMHO goes further than what we currently have in
the spec (section 2)?

> 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 06:00:53 UTC