[Author's note: throughout this document, proposed URIs are supplied in the domain for which the author's employer is authoritative. It is expected that if this document achieves a more formal status, these URIs will be replaced by URIs in domains under the authority of the XMLP or WSD or WSA working groups at W3C. The URIs in question may be searched for using the pattern: "http://www.tibco.com/xmlns/". The remainder of the path for each URI is modeled on similar URIs in the existing request-response MEP in part 2 of the specification.
This is a proposed description of the notification message exchange pattern, based on the format developed for the request-response pattern and informal discussions with those working on SOAP-related specifications, informed by the collected experience in messaging of the author's workplace, and targeted toward use in asynchronous, multiple-participant messaging systems. It is intended to help show the utility of the notification pattern in describing currently existing services, particularly those commonly characterized as "publish/subscribe". The document has no formal status whatsoever, within W3C and its working groups, or within Tibco, although it has been circulated and edited within Tibco.
The notification Message Exchange Pattern is appropriate for use in the description of services wherein the service provider sends messages requiring no response. Note that the use of notification as a "mirror" of one-way is neither discussed herein, nor considered by the authors to be useful. The common use case to be addressed is the publish/subscribe model of service provision. In this model, potential recipients are (in a fashion dependent upon protocol and binding, discussed herein) aliased to an outgoing address known to the server. Messages dispatched to that address reach all subscribers.
Interactions with Other Features and MEPs
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.
This message exchange pattern is named by the URI
http://www.tibco.com/xmlns/soap/mep/notification/
which is abbreviated to notification throughout this document.
Transport binding specifications may use the full name of this message exchange pattern to declare their support for the message exchange pattern and associated semantics described herein.
The notification message exchange pattern requires the message-addressing feature. It does not require, but does recommend, several other property sets. Implementation of the message-correlation and failure-destination features enables several different, but useful types of functionality.
This specification makes use of the following prefix mappings defined in the request-response (http://www.w3.org/2002/06/soap/mep/request-response/) specification.
Prefix | Namespace |
---|---|
context | http://www.w3.org/2002/06/soap/bindingFramework/ExchangeContext/ |
mep | http://www.w3.org/2002/06/soap/mep/ |
fail | http://www.w3.org/2002/06/soap/mep/FailureReasons/ |
The following additional prefix mappings are defined.
Prefix | Namespace |
---|---|
notify | http://www.tibco.com/xmlns/soap/mep/notification/ |
address | http://www.tibco.com/xmlns/soap/message-address/ |
Several properties defined in other specifications are reused here.
Name | Type | Constraints |
---|---|---|
context:ExchangePatternName | anyURI | |
context:FailureReason | enum | TransmissionFailure|ProcessingFailure|ReceptionFailure |
context:CurrentMessage | soap-env:Envelope | |
context:ImmediateSource | anyURI | |
context:ImmediateDestination | anyURI |
In addition, this specification defines a State property within the context namespace, rather than within its own namespace or the reqres namespace..
Name | Type | Constraints |
---|---|---|
context:State | enum | Idle|Sending|Receiving|Processing|Success|Failure |
address:original-source | anyURI | |
address:final-destination | anyURI |
The following additional property is defined for the notification MEP.
Name | Type | Constraints |
---|---|---|
notify:Role | enum | NotifyingSOAPNode|NotifiedSOAPNode |
The notification transport message exchange pattern defines a pattern for the exchange of a (conceptually single) message between a sender SOAP node and zero or more receiver SOAP nodes. One message is exchanged, in the sender to receiver direction only. The pattern may specify a single message to a single receiver only (a rare case), or a single notification from sender to multiple receivers (relying on features of the underlying binding to distribute the message, which the sender regards as despatched to a single address).
The normal operation of a message exchange conforming to the notification exchange pattern is such that the message is transferred from the Notifying SOAP Node to zero or more Receiving SOAP Nodes. Successful transmission of the message ends the exchange for the Notifying SOAP Node; Receiving SOAP Nodes end their participation in the exchange on successful processing of the message.
Abnormal operation of a message exchange conforming to the notification pattern may arise due to a failure to transfer the Notification Message, or a failure at a Notified SOAP Node to process the message. Each Notification Message SHOULD contain a fault-response address for notification of such failures, but such failures MAY be silent at any node involved in the exchange. Under abnormal operation, each SOAP node MAY differ in their determination of the successful completion of the message exchange. The Notifying SOAP Node may hold a complex value for successful completion, if multiple Notified SOAP Nodes are involved, and only some report faults.
It is recommended that bindings making use of the notification message exchange pattern with an expectation of use through intermediaries also implement the failure-destination feature.
Operation through intermediaries to single or multiple subscribers generally involves the use of the context:ImmediateDestination property, which describes the next target in the intermediary chain. The notification exchange pattern also requires that the binding specify the storage and transmission semantics of the address:final-destination property, which is the address (or alias) for the subscriber or subscribers. When using intermediaries without the failure-destination feature, faults should be propagated back to the address which is the value address:original-source property (the address:response-address property is not used in notification).
To initiate a transport message exchange corresponding to the notification transport message exchange patter, the Notifying SOAP Node instantiates a local transport message context, and enters the initial state as follows.
During the operation of the notification transport message exchange pattern, the participating SOAP Nodes may generate SOAP faults.
If a SOAP Fault is generated during the processing of a Notification Message, then relaying of that message toward the ultimate Notified SOAP Node should be terminated, whether the processing node is an intermediary or the final destination. If the failure-destination feature is bound, then the fault is directed to the fail:failure-destination address. If this feature is not bound, then the fault should be directed to the context:ImmediateSource address. If that address is unreachable, then the fault should be directed to the address:original-source address, falling back to the context:ImmediateDestination address. If that address is unreachable, no further action should be taken to report the fault.
If the message-correlation feature is not bound, the fault message should include whatever characteristics might help to connect the fault message with its triggering notification. Note that the failure-destination feature requires the message correlation feature.
Following the completion of processing of a Fail state, the failing node should perform a reset to resume initial state.
The notification pattern may be bound with only the required message addressing feature. However, there are two additional features which provide useful functionality. When bound to a synchronous protocol, which is bewilderingly pointless behavior, even the message addressing feature may default to implicit values.
Implementation of support for the notification message exchange pattern requires implementation of the message-address feature. Of the three defined properties, address:original-source and address:final-destination are required. address:response-address should not be bound or supported; the notification pattern does not support responses.
The binding of the address:original-source property should indicate an address, monitored by the sender, which uniquely identifies it. It is generally unused except for identification, but may be used for defaulting if the failure-destination feature is bound. The address:final-destination property should be bound to the address considered to be the target by the sender. This may not be a single node. address:response-address should not be bound (but is permitted, especially if the failure destination feature is supported).
Anyone silly enough to implement notification over a synchronous protocol probably deserves any interoperation nightmares that they create for themselves. But for addressing, they can bind the address:original-source to the service end of the socket, and address:final-destination to the listening end.
The message addressing feature does not depend upon any other feature. It may be used to set default values for other features, such as failure-destination, and may provide a base for external features, such as routing.
Implementors of the notification exchange pattern are encouraged to implement the failure-destination feature, but it is not required. If implemented, the single property must be bound.
The faildest:failure-destination property specifies the target for reports of errors in notifications received. Its value should be appropriate for the bound protocol. If the feature is bound, but the property does not specify a reachable address, the fallback should be to address:original-source. Applications or services may override this algorithm, typically because they have implemented some routing feature (in which case, context:ImmediateSource is an obvious target), or because they have added a binding for address:response-address.
Failure destination relies upon the message correlation feature. A fault message must contain the corr:message-id of the triggering message as the sole value of the corr:references property.
Since the notification pattern is one-way in normal operation, the message correlation feature is of use primarily for long-running conversations that include references to notifications, and for the association of faults with their triggering messages. It is optional. If implemented, corr:message-id is required, and corr:references is optionally bound.
The notification pattern adds the restriction that every message sent by a particular service should have a unique corr:message-id within a reasonable period (the ids are used to identify messages, so they should not be reused in a fashion that permits ambiguity). corr:references need not be bound (unless some other feature, or the service or application, requires it).
The failure destination feature relies upon message correlation, and requires binding not only of corr:message-id, but also of corr:references.