Feature: Failure Destination

Status

This proposal is intended to meet the requirements for a SOAP feature, as described in section 3.1 and 3.1.1 of the SOAP 1.2 Specification, with the exception that the description is not necessarily limited to "between two adjacent SOAP nodes," merely "between adjacent SOAP nodes." The document has no formal status whatsoever, within W3C and its working groups, or within TIBCO.

Motivation

During development of a number of message exchange patterns, all of which considered the difficulties of binding to asynchronous protocols, it became clear that a destination for the delivery of failure notifications (or faults) was a common requirement. It then followed that a feature embodying this property (or property set) was worthy of definition.

Definition of an explicit failure destination property for messages helps to make more explicit some of the implicit addressing and response semantics currently more commonly encountered in SOAP. The model presented here, however, suggests a means whereby an implicit failure destination may be defined, whether or not the feature is implemented. Implementation provides greater flexibility in the possible destinations, as they may then be made explicit, and even divorced from the primary participants in the exchange.

Contents

Status

Motivation

Table of Contents

Dependencies

Definitions

Description

Interactions with Other Features

Implementation as a Module

Security Considerations

References

Dependencies

Implementation of the failure-destination feature requires implementation of the message-correlation feature (which includes implicit binding, although that's a fairly pointless behavior, all things considered). A reported failure should always supply the message ID of the message for which it was generated.

Definitions

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.

Table 1: Feature Namespace and Prefix
PrefixNamespace
fdesthttp://www.tibco.com/xmlns/soap/failure-destination/

The URL for this feature (not required as with MEPs, but certainly useful) is http://tibco.com/soap/failure-destination/. Properties are defined within this namespace. The "common" namespace prefix (used throughout this document) is fdest. This feature establishes one required property which implementing bindings or modules must bind, and processors must handle.

Table 2: Properties for the Failure Destination Feature
Name Type Constraints
fdest:failure-destinationxs:anyURIRequired
fdest:failure-destination
The single property defined and required by the failure destination feature is the failure destination property, a URI valid for the protocol in use, which indicates the address to which errors are to be directed. The failure message must include the message-id of the message which caused it to be generated, and generally should contain other identifying information (a copy of the original message is possible). The property may be bound to a path; that is, it may be bound to a list of URIs. In that case, it will be transmitted through the path in order (this may require reordering of the path).

Description

Messages created in a MEP, binding, or application that implements the failure destination feature will include a binding of the fdest:failure-destination property. This property is assigned at message creation, and must not be modified during message transmission. It is used by the receiving SOAP node, when a fault is generated, to determine the address to which the fault message should be delivered.

The binding of the fdest:failure-destination property may be algorithmic, with fallbacks. Typically, the default binding is the address of the sender of the message. However, if the message-address feature is implemented (which is recommended), the preferred implicit binding of fdest:failure-destination is to address:response-address. This property, in turn, falls back to address:original-source if it is not defined.

Interactions with Other Features

The failure-destination feature depends upon the message-correlation feature. It cannot be usefully implemented without an indication of which message caused the generation of the fault.

Interaction with Message Correlation

MEPs, bindings, and applications that implement failure destination MUST also implement message-correlation. Each fault message generated should be delivered to the address specified by the fdest:failure-destination property, and should contain the value of the corr:message-id property from the triggering message as the only value of the corr:references property in the generated fault.

Implementation as a Module

The failure destination feature may be implemented as a module. It is recommended that when implemented as a module, the mustUnderstand attribute not be set true, since this may result in failures being sent to the "wrong" address in order to indicate failure to understand the header, which is fairly pointless.

  <soap-env:Header>
    <fdest:failure-destination>xs:anyURI</fdest:failure-destination>
  </soap-env:Header>

Security Considerations

The failure destination feature could be used to deliver network topology information, and machine capability information, outside the network. Applications should ensure that any address delivered to is an acceptable address for delivery.

References


Amelia A Lewis
Last modified: Fri Oct 11 12:51:26 EDT 2002