W3C home > Mailing lists > Public > public-ws-desc-comments@w3.org > September 2004

Re: binding/operation/infault|outfault?

From: Bob Cunnings <cunnings@lectrosonics.com>
Date: Thu, 9 Sep 2004 11:46:56 -0600
To: <public-ws-desc-comments@w3.org>
Message-ID: <FLEMLMIOFOCLIONKMOLPGEJJCCAA.cunnings@lectrosonics.com>


It's not that I want to bind a common fault differently to various
operations. Rather, I wanted to somehow associate a particular SOAP module
with a particular Interface Fault component. It doesn't necessarily have to
be at the operation level.

The purpose in mind was to specify a particular soap module (embodied in a
header element) that would be present in a particular Fault message to carry
additional information "out of band" with respect to the application
generating the Fault. This module is not associated with any other message.

IIRC when the binding/operation/outfault was available, the the association
could be made via a wsoap:module component.

Since faults are now at the interface level, would it make sense for
binding/fault to contain a SOAP module component? That would do the job,
unless I'm missing something here.



I believe they were removed when we lifted faults to the interface level
and introduced Interface Fault components. Since faults are now shared
by multiple operations, they can only be bound once in an interface
by using a Binding Fault component.

For example, it's not possible for a single fault, used by three
different operations, to result in SOAP faults with different fault
codes depending on which operation was being invoked when the fault
was raised. I vaguely remember the WG discussing this case at
the January 2004 F2F hosted by Sonic.

If there is a genuine need for allowing different operations in the
same interface to bind the same fault differently, we may want
to (re-)introduce a Binding Fault Reference component. So please
tell us more about your use case.

Received on Thursday, 9 September 2004 17:47:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:05:56 UTC