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 proposal includes a recommendation that the feature be regarded as standard, that is, that it be a required feature for every binding. A discussion of how this may be implemented in a fashion compatible with existing implementations (which rely upon implicit correlation resulting from a synchronous messaging model) is included. The document has no formal status whatsoever, within W3C and its working groups, or within TIBCO.
The message-addressing feature has been developed as a means of modularizing several commonly-encountered properties. All of these properties relate to addressing of messages, and are encountered in both synchronous and asynchronous protocol bindings. Because synchronous bindings allow these properties to be implicitly understood, rather than requiring them to be explicitly defined as is common for asynchronous protocol bindings, this feature has more obvious relevance to asynchronous bindings. Nonetheless, this description outlines how the properties may be bound to implicit addresses, as well as providing guidance for explicit bindings.
While developing the specifications for several message exchange patterns, in each of which consideration was given to binding to asynchronous protocols, it was found that each MEP needed to define the origination address, target address, and (for multi-message MEPs) an optional response address. There are some differences in interpretation (for instance, a target address may be a single node, or an alias for a collection of nodes or a transmission path to which multiple nodes are attached), but the basic properties seemed to have more commonality than differences. These properties have therefore been abstracted into this property set, or feature.
Further reflection tends toward the conclusion that, although the request-response message exchange pattern does not specify explicit values for these properties, it nonetheless implicitly binds them to the currently open socket. It therefore seems appropriate to suggest that this feature is universal, and ought to be considered standard.
Interactions with Other Features
The message-addressing feature does not depend upon any other feature. Most bindings implementing this feature should also implement message-correlation, but it is possible to imagine a situation in which it is unnecessary.
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.
Prefix | Namespace |
---|---|
address | http://www.tibco.com/xmlns/soap/message-address/ |
The URL for this feature (not required as with MEPs, but certainly useful) is http://www.tibco.com/xmlns/soap/message-address/. Properties are defined within this namespace. The "common" namespace prefix (used throughout this document) is address. This feature defines two required, and one optional property.
Name | Type | Constraints |
---|---|---|
address:original-source | xs:anyURI | Required |
address:final-destination | xs:anyURI | Required |
address:response-address | xs:anyURI | Optional |
The message addressing feature makes explicit three addresses which are commonly encountered, often implicitly, in most network message exchanges. These addresses are expressed in this description as properties. Message exchange patterns (rarely), bindings (usually), and applications (occasionally) may specify the binding of each of these properties to a particular storage location. In most cases, the location of the values of the required properties (original-source and final-destination) should be such that they can be transmitted with (as metadata) or as a part of (as data) the message itself. The response address, an optional property (particularly so for exchange patterns that contain only one message) is also provided as a commonly used, commonly useful address.
Implementation of the message addressing feature requires binding of the two required properties (original-source and final-destination). The response-address may be bound. The values of all three properties should be URIs appropriate for the protocol, or the special value indicating the currently open socket (for synchronous protocol bindings).
address:original-source is set at message creation, and should not be changed. address:final-destination is also set at message creation, and should not be changed. When a message is created in response to another message (the context:TriggerMessage), the new message should derive its response address from the address:response-address property of the triggering message, if that property is bound.
Message addressing is a relatively fundamental feature, with no external dependencies. It is easily implemented without implementation of other features. However, it is worth noting how it may support implementation of other features (by provision of default values or starting points, for instance), and may not provide complete capability if implemented alone (asynchronous protocol bindings, as a rule, require implementation of both message correlation and message addressing).
The message addressing feature provides independence from the implicit addressing semantics of synchronous protocol bindings, but does not correlate messages. Many exchange patterns contain multiple messages. While the message addressing feature can provide information about how these messages move back and forth, it does not provide a means of relating one message to another. As a general rule, an asynchronous protocol binding that supports multiple-message exchange patterns must implement both the message addressing feature and the message correlation feature. Synchronous protocol bindings are free to do so as well, although in general the binding of both addressing and correlation will be to the currently-open socket over which the exchange occurs (this becomes much more complex for exchanges involving intermediaries, of course).
A common definition of the failure destination feature's default value is the value of the message addressing feature's response address property (which itself often defaults to the value of the original source property). These features are, however, conceptually independent. Either can be implemented alone, and both may be implemented together.
Protocol bindings should not, as a rule, implement this feature as a module. Every protocol binding is likely to contain these properties in some form; binding them to the native representations for that protocol is a better, more robust form of implementation. However, should a protocol binding lack certain semantics that would be better served by implementation as a module, the following outline may be useful.
<soap-env:Header> <address:message-address> <address:original-source>xs:anyURI</address:original-source> <address:final-destination>xs:anyURI</address:final-destination> <address:response-address>xs:anyURI</address:response-address>? </address:message-address> </soap-env:Header>
The message addressing feature poses no interesting security problems. It has some obvious relevance to issues of privacy and of authentication/identity, but in general those are features that might be built on top of this feature, or that might have to work around it (in the case of privacy/anonymity).