Message Exchange Pattern:
Asynchronous Request/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 request-response MEP in part 2 of the specification.

Status

This is a description of an alternative request/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. 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

In the process of developing descriptions and specifications for a number of features, message exchange patterns, and bindings associated with the publish/subscribe model (and with which this document is distributed), it became clear that two features, message-correlation and message-addressing were actually implicitly defined in the existing request/response message exchange pattern description. However, this implicit specification requires binding to a synchronous protocol, and does not permit of any identification or addressing alternatives other than those implicitly specified.

This description addresses that concern. Because the protocol bindings presented in this set of proposals are asynchronous, support for any request/response binding should also demonstrate its use when bound to an asynchronous protocol. This turns out to be relatively straightforward, and in the end more flexible than the implicit binding of the original specification. Because the properties exposed in this alternate description are explicitly enumerated, they can be bound to the same targets as they are in the original description--that is, to the endpoints of an open socket. It thus follows that this alternate description may effectively replace the more limited original description.

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/asynchronous-request-response/

which is abbreviated to arr 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.

Required Features

The asynchronous request/response message exchange pattern requires implementation of the message-correlation and message-address features, and recommends implementation of the failure-destination feature. This is the chief distinction between this message exchange pattern and the patten described in part two of the XML Protocol specification.

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.

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.

PrefixNamespace
notifyhttp://www.tibco.com/xmlns/soap/mep/asynchronous-request-response/

Properties

Several properties defined in other specifications are reused here.

Name Type Constraints
context:ExchangePatternName anyURI
context:FailureReason enum TransmissionFailure|ProcessingFailure|ReceptionFailure
context:CurrentMessage message
context:ImmediateSource anyURI
context:ImmediateDestinationanyURI
corr:message-id string unique
corr:references array of string
address:original-source anyURI
address:final-destination anyURI
address:response-address anyURI

In addition, this specification defines the State property within the context namespace, rather than within its own namespace or the reqres namespace. It also defines the TriggerMessage in the context namespace.

Name Type Constraints
context:StateenumIdle|Sending|Receiving|Processing|Success|Failure
context:TriggerMessagemessage

The following additional property is defined for the asynchronous request/response MEP.

Name Type Constraints
arr:Role enum RequestingSOAPNode|RespondingSOAPNode
arr:Role
The arr:Role property, like the Role property in other exchange pattern definitions, defines the role that a particular processor is playing in the exchange. In this case, the permissible values are "RequestingSOAPNode" and "RespondingSOAPNode". An intermediary will take on both roles sequentially (responding for the receiving portion of the stat, requesting for the whole of that role, then completion of the responding state).

Informal Description

The asynchronous request/response exchange pattern differs from the "standard" (that is, implicitly synchronous) pattern in several ways. It makes explicit the origination and destination addresses (arr:OriginalSource and arr:FinalDestination properties). It requires the use of the message correlation feature (both corr:message-id and corr:references are required). It replaces the awkward InboundMessage and OutboundMessage in the reqres namespace with CurrentMessage and TriggerMessage in the context namespace, and also moves the State property into the context namespace (since every pattern imaginable will have state, and the state is generally expressible in generic terms). Implementation of the failure-destination feature is also encouraged.

Basic Operation

All pretty much as before, except that the original requesting node also sets the message id, original source, and final destination properties. Out it goes, and the responding node gets it, and performs a transform in which current message becomes trigger message, a new current message is created, and the message's properties are set up using the values in trigger message plus the results of processing. The response address is calculated from properties in the trigger message, and the message id of the trigger message becomes the references field (or is added to the existing references field in the trigger message) of the current message. What fun.

Operation through Intermediaries

The primary properties used during operation through intermediaries are context:ImmediateSource and context:ImmediateDestination. Features that specify properties associated with routing are otherwise not discussed here.

Formal Description

Basic Operation

Operation through Intermediaries

Fault Handling

Fault handling remains much of a muchness, except when the optional failure-destination feature makes more of it. The message-address feature may also be mined for potential destinations for fault messages. Note that in solicit/response, a fault on a solicitation is never delivered to a respondent, whereas a fault on a response may be delivered to the ... err, solicitor. Perhaps the same thing should happen here? That is, a fault in the request should never be delivered to the service, but a fault in the response can be delivered to the first place that takes it (service first, but if you can't get to there and can get to the requester, do so).

Interactions with other Features and MEPs

Implementation of the asynchronous request/response message exchange pattern requires implementation of two features. These two features distinguish asynchronous request/response from the original specification of the request/response pattern, but asynchronous request/response can also use implicit binding to reproduce the effect of that specification.

When this message exchange pattern is bound to a synchronous protocol, the properties should simply be bound to the implicit addresses/identifiers 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 asynchronous request/response patterh requires implementation of support for the message correlation feature. The corr:message-id and corr:references properties are both required.

The corr:message-id property must be unique for the exchange. It is preferred that it be more generally unique, but only required that it be unique for the exchange between the two parties involved. The corr:references property may be omitted in a request 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 triggering message, with the value of the triggering message's corr:message-id property prepended. If there is no corr:references property in the triggering message, the corr:references property of the response message contains only the value of the request message's corr:message-id property.

If bound to a protocol with synchronous semantics, corr:message-id and corr:references may be bound (implicitly or explicitly) to the endpoints of the open socket.

If implemented, the failure-destination feature requires message correlation. Correlation does not depend on any other feature.

Message Addressing Feature

The message-address feature is required for implementation of the asynchronous request/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 request message, this is typically the response address. In a response address, it is generally the service address. The value of the address:final-destination should be the address of the target, as known to the sender. For the request message, this is usually the well-known address of the service, as described in its service description. For the response message, it is a value taken from the request message, with the following algorithm. If the request message contains an address:response-address property, then the address:final-destination of the response message should be that address. If address:response-address does not exist, is invalid or cannot be reached, the response should be directed at the address:original-source of the request message. The response message need not bind the value of the address:response-address property.

When bound to a protocol with synchronous semantics, address:original-source of the request message may be bound to the opening side of the communication; this is also address:final-destination of the response message. The other end of the socket is bound to address:final-destination of the request message and address:original-source of the response message.

Message addressing does not require any other feature. The failure destination feature may make use of its properties, as defaults. Larger-scale routing conecerns may require additional features, which should in general be compatible with, and should make use of, the message addressing feature.

Failure Destination Feature

The failure-destination feature is optional, but recommended, for services that implement the asynchronous request/response message exchange pattern. If supported, its single property is required.

The faildest:failure-destination property must contain a value valid for the protocol bound. This specification requires that if there is no explicit value assigned for the faildest:failure-destination property, then the fault message should be routed to the originator of the message (that is, to the address specified as the value of the address:original-source property in the triggering message). If no explicit value is set, and the address in the address:original-source property is unreachable, the fault message is dropped.

The failure-destination feature requires the message correlation feature. In the context of the asynchronous request/response pattern, it also requires the message addressing feature to establish a default destination. Every message must contain the corr:message-id of the message that triggered the fault as the value of its corr:references property, and the target destination, if not otherwise explicitly bound, is the value of the address:original-source property.

Notes

There is a strong tendency among some to propose that request/response is the mirror of solicit/response (although this is usually expressed in the other direction). It is worth noting, then, the differences between the specifications (see the solicit/response message exchange pattern definition) when discussed in terms of properties. The features required and recommended are basically the same, but the solicit/response includes a fairly chunky set of additional properties related to termination conditions.

The basic difference, then, is that a solicit/response pattern expects multiple respondents (and so must handle that special case, of when to terminate, itself), because a service might reasonably be expected to have multiple subscribers. On the other hand, very few proponents would argue that a service should be sending multiple responses to a single request. In order to use (asynchronous) request/response to "mirror" solicit/response, one is required to suggest that the service being targeted by the request is multiple, potentially contradictory, and able to easily cope with the digestion of one message multiple times. Thus, it seems unfair to characterize the various subscribers as some "virtual" service, and far more useful to speak of the publisher as the service.

References


Amelia A Lewis
Last modified: Fri Oct 11 16:14:18 EDT 2002