- From: Bob Cunnings <cunnings@lectrosonics.com>
- Date: Tue, 22 May 2001 11:59:42 -0700
- To: xml-dist-app@w3.org
Hello, 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. RC > > 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