W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2001

Re: Finding Faults in headers

From: Bob Cunnings <cunnings@lectrosonics.com>
Date: Tue, 22 May 2001 11:59:42 -0700
To: xml-dist-app@w3.org
Message-ID: <3B0A54B0.28286.29DD9ED5@localhost>

No coordination is needed.

Speaking of the implementation here...

If a header module handler faults, it passes fault string, fault code, 
and any fault header entries back to the SOAP processor, which 
constructs the SOAP envelope (with fault element in body) and 
ships it back to the caller. The body handler hasn't even run yet in 
this case, but it's participation isn't needed anyway.

Although the details of the fault generation mechanism will vary 
with the implementation, the principle should hold for all that 
header handlers will generate faults independently. The body being 
just a "specially designated header" in a sense, its handler has the 
same duties and responsibilities as any header handler in terms of 
fault generation, but no more.

So there's actually no coupling between the handlers... they 
process successfully or fault separately (of course they are 
accessing the same message object to get their data inputs).

The SOAP processor manages the invocation of the handlers and 
constructs any fault message to be returned. The generation of a 
fault is the result of collaboration between the processor and the 
faulting handler, not between any two handlers.

At least that's how we do it. There must certainly be other ways to 
structure SOAP message processing.

> > The notion of orthogonality is right on and can
> > indeed be taken advantage of to provide a simpler dispatch mechanism in
> > the implementation.
> I'm not sure I buy into that, since the body is just a specially
> designated header.  In addition, it seems to me that the header-module
> now must coordinate with the body-module to fault a message.  But I
> readily admit my inability to "not see" this as a tight coupling is
> probably my own, er, fault.
> 	/r$
Received on Tuesday, 22 May 2001 14:00:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:13 UTC