Message Exchange Pattern:
Solicit-Response

[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 definition of the request-response MEP in SOAP part 2.

Status

This is a proposed description of the solicit-response 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 show the utility of the solicit/response 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 Software Inc., although it has been circulated and edited within Tibco.

Motivation

The solicit-response Message Exchange Pattern is appropriate for use in description of services wherein the server initiates message exchanges. Note that the use of solicit/response as a "mirror" of the request/response pattern 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 respondents are (in a fashion dependent upon protocol and binding, not discussed herein) aliased to an outgoing address known to the server. Messages dispatched to that address reach all subscribers, who may choose to respond. The operation described may limit the number of permissible responses (by number, order of receipt, or time). Since messages are transmitted to multiple respondents, and multiple messages may be outstanding, and the protocols bound are typically asynchronous, message identity and correlation is required. This specification also describes the "degenerate" case of a server solicitation with synchronous (and therefore single) response.

Table of Contents

Status

Motivation

Table of Contents

Definitions

Informal Description

Formal Description

Fault Handling

Interactions with Other Features and MEPs

Notes

References

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.

Message Exchange Pattern Name

This message exchange pattern is named by the URI

http://www.tibco.com/xmlns/soap/mep/solicit-response/

which is abbreviated to solicit-response throughout this document.

Transport binding specifications may use the full name of this transport message exchange pattern to declare their support for the transport message exchange pattern and associated semantics described herein. Where behavior is described as requiring clarification from the binding, the binding should provide further specification.

Required Features

In its target use case (publish/subscribe services), solicit-response is an asynchronous message exchange pattern. That is, unlike the request-response pattern, in which message correlation is implicit and assumed to be associated with a synchronous pattern (that is, responses are received over the same connection opened to transmit the request; this may also be called a 'single-connection' pattern), there is no obvious implicit means of associating an incoming response with its originating solicitation. Therefore, implementation of the full solicit-response pattern semantic requires implementation of the message-correlation feature. This specification adds further restrictions to the definition of the message-id property in Message Correlation: the id of both outgoing and incoming messages must be unique within a larger scope (determined by the application). A good rule of thumb is attempted universal uniqueness, with message-ids that reflect at least the sender and the time of transmission. That is, this specification mandates uniqueness of ids not only within a single conversation, but among conversations as well. Details of the location of the property, however, are left to the binding implementing this MEP and the message-correlation feature.

For similar reasons, this pattern mandates the use of the message-addressing feature. When used synchronously, the binding of properties in the feature may be to the currently-open socket, but this should be made explicit in the binding, not allowed to be implicit.

This specification also recommends, but does not mandate, implementation of the failure-destination features, because the default asynchronous nature of the pattern also removes the default value for this property that is implicit in a synchronous pattern.

Prefix Mappings

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.

Table 1: Externally Defined Namespaces with Prefixes
Prefix Namespace
contexthttp://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.

Table 2: Additional Namespaces and Prefixes
PrefixNamespace
solicithttp://www.tibco.com/xmlns/soap/mep/solicit-response/
addresshttp://www.tibco.com/xmlns/soap/message-address/
corr http://www.tibco.com/xmlns/soap/message-correlation/

Properties

Several properties defined in other specifications are reused here.

Table 3: Externally Defined Properties, with Types and Constraints
Name Type Constraints
context:ExchangePatternName anyURI
context:FailureReason enum TransmissionFailure|ProcessingFailure|ReceptionFailure
context:CurrentMessage message
context:ImmediateSource anyURI
context:ImmediateDestinationanyURI
address:original-source anyURI
address:final-destination anyURI
address:response-address anyURI
corr:message-id string unique
corr:references array of string

In addition, this specification defines a State property within the context namespace, rather than within its own namespace or the reqres namespace. The TriggerMessage property is also added (appropriate only for multiple-message patterns).

Table 4: Additional Properties, with Types and Constraints
Name Type Constraints
context:State enum Idle|Sending|Receiving|Processing|Success|Failure
context:TriggerMessagemessage

The following additional properties are defined for the solicit-response MEP.

Name Type Constraints
solicit:Role enum SolicitingSOAPNode|RespondingSOAPNode
solicit:TermCondition enum First|Number|Time|Notification
solicit:Synchronous boolean
solicit:NumRespondents int
solicit:Deadline dateTime
solicit:Role
The solicit:Role property, like the Role property in other exchange pattern definitions, defines the role that particular processor is playing in the exchange. In this case, the permissible values are "SolicitingSOAPNode" and "RespondingSOAPNode". An intermediary, if present, will play these roles sequentially (typically in the order: responding, soliciting, responding, where the responding node's states are divided into two sections (receiving versus sending)).
solicit:Synchronous
Since the exchange pattern is presumed asynchronous (and multiple-recipient), a single property is able to signal the less common usage for synchronous (and typically single-recipient/respondent) operation. If the property is not set, it is presumed false. It is the responsibility of the binding to indicate how the property may be set true, if it is supported. Note, however, that synchronous operation is optional, and need not be supported by a protocol binding. If the synchronous property is set (to true, that is), then the properties solicit:TermCondition, solicit:NumRespondents, and solicit:Deadline are ignored. A RespondingSOAPNode may not change the value of the synchronous property.
solicit:TermCondition
Unless the synchronous property is set, the solicit:TermCondition property is the primary indicator of how the exchange pattern will end. It is an enumeration in which the legal values are "First", "Number", "Time", and "Notification". If the property is set to "First," then the solicit:NumRespondents and solicit:Deadline properties are ignored. The first response received ends the pattern for the SolicitingSOAPNode, which may ignore further responses or refuse them (the protocol binding should specify this). Identical behavior may be achieved if the value of the termination condition is "Number" and solicit:NumRespondents is any number less than two. If the value of the termination condition is "Number", then the value of the solicit:NumRespondents property will be used to determine how many messages will be received before the operation is ended at the SolicitingSOAPNode. If the value of the termination condition is "Time", then the value of the the solicit:Deadline property will be used to determine the last moment at which a response may be received at the SolicitingSOAPNode (but if the solicit:Deadline value is missing or corrupt, then the exchange terminates by the rules of the Notification condition). If the termination condition is Notification (or if the termination condition is missing or invalid, or the associated property indicated by the condition is missing or invalid), then the pattern may only be ended when the SolicitingSOAPNode sends a notification message to the same address as the original solicitation, indicating that responses will no longer be accepted. Transmission of the notification may be considered the end of the exchange pattern for the SolicitingSOAPNode.
solicit:NumRespondents
The solicit:NumRespondents property is a positive integer which is consulted if, and only if, the termination condition property is "Number". If termination condition is "Number", then the value in NumRespondents is consulted, and each response message received is counted. Once the number specified has been received, the exchange is completed for the SolicitingSOAPNode, which may then ignore or refuse any additional responses (as specified by the protocol binding). If the number is one or less, it is treated as one.
solicit:Deadline
The solicit:Deadline property is an xs:dateTime (or the equivalent, conforming to ISO semantics), always including a timezone, which indicates the last moment for receipt of responses. If the property is set, and the termination condition is "Time", then the SolicitingSOAPNode completes operation at the specified time and date. If the property is unset or invalid, and the termination condition is "Time", then the termination condition is treated as "Notification" instead.

Informal Description

The solicit-response transport message exchange pattern defines a pattern for the exchange of a (conceptually single) message from a sender SOAP node and the receipt of zero or more responses from receiver SOAP nodes. The pattern may specify a single solicitation from sender to receiver and a single response from receiver to sender, or a single solicitation from sender to multiple receivers (usually relying on features of the underlying binding to distribute the message, which the server will continue to regard as a single address) with zero or one response from each receiver (totalling zero or more responses to the solicitation).

Basic Operation

The normal operation of a message exchange conforming to the solicit-response exchange pattern is such that the soliciting message is transferred from the Soliciting SOAP Node to zero or more Responding SOAP Nodes. After successful processing of the Solicitation Message, each recipient MAY construct and return a response message, unless the service operation description requires a response, in which case each recipient MUST construct and return a response message. The Soliciting SOAP Node may receive both successful responses and faults for the same Solicitation Message (from different respondents). The exchange is considered complete when the Soliciting SOAP Node stops processing Response Messages.

The termination condition is encoded into the service description. The properties interact: the TermCondition property specifies the type of termination condition, which may be "First", "Number", "Time", or "Notification." If the condition is "First," only one response (the first to received) will be accepted. If the condition is "Number," then the value of the NumRespondents property indicates the number of responses which will be accepted. TermCondition="Number" and Number="1" is equivalent to TermCondition="First". If TermCondition is "Time," then the Deadline property contains the last moment at which a message will be accepted (note that this is time of receipt, not time of transmission of the response). More complex, application-defined algorithms for termination are also possible, but are modelled using the "Notification" type. If this is the termination condition, then a notification (see the Notification Message Exchange Pattern specification) will be the signal ending this exchange. A special type of solicit-response exchange may be indicated if the Synchronous property is set to "true" (it is false by default). In this case, only a single response is expected, over the connection opened to deliver the solicitation. See Synchronous Operation, below.

Solicitation messages conforming to the pattern must contain a message-id (except when the Synchronous property is set to true) and a TermCondition. The type of TermCondition may require other properties. Solicitation messages may, but are not required to, contain a ResponseAddress property (indicating the target for the corresponding response message) and a references property (to indicate the conversation). Solicitation messages are required to carry the OriginalSource property, and should carry information sufficient to construct or determine the FinalDestination property, which is identical to the published target address.

Response messages conforming to the pattern must contain a message-id and a references property (except when the synchronous property is set to true). The FinalDestination property should be set from the solicitation message's ResponseAddress property (if there is one), or the OriginalSource property (which must always exist). Response messages should not be associated with the TermCondition property on the side of the responding node (although they may trigger termination on the service side).

Abnormal operation of a message exchange conforming to the solicit-response pattern may arise due to a failure to transfer the Solicitation Message, a failure at a Responding SOAP Node to process the message, or a failure to transfer a Response Message from the Responding SOAP Node to the reply address. Each Solicitation 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 Soliciting SOAP Node may hold a complex value for successful completion, if multiple Responding SOAP Nodes are involved, some responding successfully and others reporting faults.

Operation Through Intermediaries

Operation through intermediaries is generally achieved, hop-by-hop, using message correlation with some path indicators, the minimum of which are context:ImmediateSource and context:ImmediateDestination.

When a solicitation message passes through an intermediary, that intermediary first takes on the role of a RespondingSOAPNode, in the states receiving and processing. It then, in effect, freezes operation as a responding node, and adopts the role of SolicitingSOAPNode with respect to the next hop. When it completes its state in that role (possibly sending one message and receiving multiples; possibly sending multiples and receiving one response from each, possibly some other pattern), then it completes the state transitions for a responding SOAP node (with sending and completion states).

The actual behavior of the intermediary depends upon the multiplicity of its inputs and outputs. In the common case, all intermediaries are chained before the message is "exploded" to its recipients. In this case, although all intermediaries expect to send a single solicitation message, they may receive multiple responses. Intermediaries should never ignore or refuse a response message, even if the intermediary is able to know that the message will not be accepted. Ignoring and refusing messages should be the prerogative of the final destination of the response message.

An intermediary implemented as one subscriber (of potentially many) is underspecfied, for now.

Synchronous Operation

In some circumstances, it may be useful to define the solicit-response pattern as synchronous. When operating asynchronously, features and properties related to message identification and correlation, addressing, and routing between intermediaries or of faults, is all described to be "implicit." That is, message correlation is handled because the originating socket remains open for an answer. The return path and return address (for this hop) are the currently open socket used for delivery of the solicitation message. The fault destination, unless specified differently, is also implicitly bound to the open socket. (The reason that the original request/response exchange pattern specification is able to appear to be so simple is because these implicit properties are neither identified nor allowed to be modified) Since this pattern makes this explicit, it also permits the binding to specify alternatives (which includes the ability to mix synchronous and asynchronous protocol bindings, although only within the limits of the timeouts of synchronous sockets).

The synchronous variant for solicit/response always has a single SolicitingSOAPNode and a single RespondingSOAPNode. The exchange pattern completes after the receipt of the response, which is required (it is optional for subscribers in the asynchronous model), and the success/failure state of the completed exchange is neither complex nor ambiguous.

Formal Description

Basic Operation

Operation through Intermediaries

Syncronous Operation

Fault Handling

During the operation of the solicit-response transport message exchange pattern, the participating SOAP Nodes may generate SOAP faults.

If a SOAP Fault is generated during the processing of a Solicitation Message, then relaying of that message toward a Responding SOAP Node should be terminated, and the generated SOAP Fault should be propagated toward the address specified in the fdest:FailureDestination property. If there is no such property, the context:ImmediateSource property may be used, and if it does not exist or cannot be reached, the address:response-address (which defaults to address:original-source) property address may be used. If no destination is available or reachable, the Fault Message must be discarded. Under no circumstances may generation of a fault in handling a Solicitation Message result in delivery of a fault message to any Responding SOAP Node.

If a SOAP Fault is generated during the transmission or processing of a Response Message, then relaying of that message toward the Response Address should be terminated, and the generated SOAP Fault should be propagated toward the address specified in the fdest:FailureDestination property. If there is no such property, the context:ImmediateSource property may be used, and if it does not exist or cannot be reached, the address:response-address property address may be used. If originator addresses are not reachable, the Fault Message may be delivered to the context:ImmediateDestination or context:FinalDestination address, if they are reachable (this is in distinction to the handling of a fault occurring during processing of a Solicitation Message, which forbids delivery of the faults to the Responding SOAP Nodes).

Following the completion of processing of a Fail state, each node should perform a reset to resume initial state.

Interactions with Other Features and MEPs

Implementation of the solicit/response pattern requires implementation of two features, and strongly recommends the implementation of another. All of these features have to do with message identification and addressing; the properties exposed by these features are made explicit in the solicit/response pattern, unlike the request/response pattern, because the working assumptions are that the bound protocol may be asynchronous, and that multiple responses may be received.

When solicit/response is used in a synchronous, single-response service, these features seem less obviously needed, but in such a case, the properties should simply be bound to the implicit addresses (and ids) represented by the socket opened for the communication. That is, the properties should be bound explicitly, rather than relying upon the implicit binding. For compatibility, though, a lack of such explicit property bindings, in the context of a synchronous protocol, is hereby declared to represent an implicit binding of these properties to the open socket. In context of a binding to an asynchronous protocol, failure to specify the bindings is an error.

Message Correlation Feature

Implementation of the mechanics of the solicit/response message exchange pattern requires implementation of support for the message-correlation feature. The corr:message-id and corr:references properties are both required.

The corr:message-id feature must be unique for all participants in a single solicit/response exchange. It is recommended that the origination address be a part of the id. The corr:references property may be omitted for a solicitation message, but is required for a response. In the response message, the corr:references property SHOULD contain the value of the corr:references property of the solicitation message, with the value of the solicitation message's corr:message-id property prepended. If there is no corr:references property in the solicitation message, the corr:references property of the response message contains only the value of the solicitation message's corr:message-id property.

If bound to a protocol with synchronous semantics, corr:message-id and corr:references may be bound implicitly to the endpoints of the open socket. The service or application making such usage must specify it in its description.

If implemented, the failure-destination feature requires message correlation. Correlation requires no other features.

Message Addressing Feature

The message-address feature is required for implementation of the solicit/response message exchange pattern. All three properties, address:original-source, address:final-destination, and address:response-address are required.

address:original-source must contain a value representing an endpoint which the sender is able to monitor. In a solicitation message, this is the service address; in a response, it is the specific address of the respondent (which is usually different from the value of the address:final-destination property of the solicitation message, for asynchronous bindings). The value of the address:final-destination need not represent a single receiver. It represents the target address from the sender's point of view, which may be an alias for a number of possible respondents, a multicast address, or something similar. The address:response-address must be bound for a solicitation message, but the binding may be to the address:original-source default. Respondents should set the address:final-destination property of the response message to, first, the value of the address:response-address property of the solicitation message, then to the value of the address:original-source property. The response message need not bind the address:response-address property.

Message addressing does not require any other feature. The failure destination feature may use some of the properties it defines as defaults. Larger-scale routing concerns may require additional features, which should then combine well with (and probably depend upon) message addressing.

Failure Destination Feature

The failure-destination feature is optional, but recommended, for services that support the solicit/response message exchange pattern. If supported, its single property, faildest:failure-destination, is required.

The faildest:failure-destination property must contain a value valid for the protocol bound. This specification requires that if no explicit value is assigned for the faildest:failure-destination property, that a particular algorithm to select a destination be used, depending upon whether the message triggering the fault is a solicitation or a response (see Fault Handling).

The failure-destination feature requires the message correlation feature. Every fault must contain a corr:references property which contains the value of the corr:message-id property of the triggering message.

Notes

The solicit/response pattern may be used in a variety of publish/subscribe, and a few point-to-point models of service provision. Generally speaking, for the point-to-point, synchronous model of solicit/response, the pattern is used in combination with some other pattern that establishes the identity of the target receiver with the target address, in some fashion (that is, the synchronous solicit/response typically requires pre-registration, probably via one-way or request/response operations, although others are possible). The requirements of publish/subscribe vary widely. For instance, mailing lists delivered via internet email are likely to require that receivers (potential respondents to a solicitation) register in advance. The list email address acts as an alias and exploder for all the members of the list. On the other end of the spectrum, a newsgroup reader may not have to inform any server anywhere that the group is being monitored (and possibly responded to). The general principle is that the respondents are represented by a single address, but the sender cannot know in advance how many will receive the message (or if any will).

The pattern of registration (or in general, administration of membership) prior to use of list-oriented services, is not described here. It is assumed that each subscriber is able to subscribe; the service describes the publisher's side only. For services in which subscription is equivalent to registration as a publisher, more advanced techniques may be necessary in the service description language.

References


Amelia A Lewis
Last modified: Fri Oct 11 16:13:28 EDT 2002