[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 confirmation message exchange pattern, based on the format developed for the request-response pattern and informal discussions with those working on SOAP-related specifications, and informed by the collected experience in messaging of the author's workplace. 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.
The confirmation message exchange pattern describes a common pattern used when a one-way action requires some form of in-context confirmation in order to be approved. The classic case is double-opt-in subscription for mailing lists. It is argued here that the pattern is inadequately described as the combination of one-way plus solicit/response or as the combination of request/response plus one-way. That is, this message exchange pattern description proposes, by example, that the current set of exchange patterns is not only not in need of truncation, it is too small to adequately describe common and useful operations that should be amenable to description for a web service.
The pattern is composed of three messages, which are informally referred to as presence (an input message), challenge (an output message), and confirmation (an input message that ends the exchange, changing state on the client, the server, or both).
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/confirmation/
which is abbreviated to confirmation 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.
Although the confirmation message exchange pattern could use the implicit addressing and correlation semantics expressed in earlier models (notably the request/response message exchange pattern), much greater applicability is possible if the message-correlation and message-addressing features are used. They are therefore required. The failure-destination feature is also recommended.
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 |
|---|---|
| confirm | http://www.tibco.com/xmlns/soap/mep/solicit-response/confirmation/ |
| address | http://www.tibco.com/xmlns/soap/message-address/ |
| corr | http://www.tibco.com/xmlns/soap/message-correlation/ |
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:ImmediateDestination | anyURI | |
| 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 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).
| Name | Type | Constraints |
|---|---|---|
| context:State | enum | Idle|Sending|Receiving|Processing|Success|Failure |
| context:TriggerMessage | message |
The following additional property is defined for the confirmation MEP.
| Name | Type | Constraints |
|---|---|---|
| confirm:Role | enum | RequestingSOAPNode|ChallengingSOAPNode |
The confirmation message exchange pattern defines an exchange of a message from a single initial presenter, which is challenged by the service, followed by a confirmation message by the initial sender. There are only two participating nodes (apart from intermediaries). State change occurs, typically on the server, only when the third and final message is successfully processed.
The normal operation of a message exchange conforming to the confirmation pattern is such that the presence message is transferred from the RequestingSOAPNode to a single ChallengingSOAPNode. After successful processing, the Challenging SOAP Node constructs a challenge message, which it returns to the Requesting SOAP Node, or to the address specified as the response address of the presence message. When the Requesting SOAP Node has successfully processed the challenge message, it returns the confirmation message to the response address specified in the challenge message, or the source of the challenge message, or the original target address of the presence message. The exchange is considered complete when the Challenging SOAP Node successfully processes the confirmation message, or when either node generates a fault due to processing, transfer, or delay.
The presence and challenge messages both should contain a valid value for the address:response-address property. All messages in the exchange must contain valid values for the address:original-source and address:final-destination properties (although in a synchronous protocol with implicit property binding, these properties may not be highly visible). All messages in the exchange must contain a corr:message-id property, which must be unique for this exchange (at minimum). The challenge message's corr:references property MUST contain the value of the presence message's corr:message-id property as its first value (it may contain other values as well, for a longer-running conversation). The confirmation message's corr:references property MUST be constructed by prepending the challenge message's corr:message-id property to the value of the challenge message's corr:references property. When bound to a synchronous protocol, however, these identifiers and references may be bound (explicitly or implicitly) to the endpoints of the open socket.
Abnormal termination of a message exchange conforming to the confirmation pattern may arise due to a failure to transfer the presence message, a failure of the Challenging SOAP Node to process the presence message, a failure to transfer the challenge message to the response address, a failure of the Requesting SOAP Node to process the challenge message, a failure to transfer the confirmation message to the Challenging SOAP Node, or a failure of the Challenging SOAP Node to process the confirmation message. In the event of abnormal termination, the endpoint generating the fault should communicate it to the other endpoint; both endpoints should agree on the success or failure of the exchange at completion (however, because there is no guarantee that the fault message can be delivered, there is also no guarantee that this sharing of state will occur).
to be written. Not clear whether impact of intermediaries is significant for this pattern.
During the operation of the confirmation message exchange pattern, the participating SOAP Nodes may generate SOAP faults.
If a fault is generated during the transfer or processing of the presence message, then the operation should be terminated. If the failure-destination feature is implemented, the fault should be directed toward the address specified by the faildest:failure-destination property. If the feature is not implemented, or the property is not specified or its value is unreachable, the fault is propagated to the destination specified in the address:response-address property (which should always exist), and if this is for any reason not possible, then toward the address specified in the address:original-source property. If none of these addresses are reachable, the fault should be dropped.
Faults occurring during the transfer or processing of the challenge message and the confirmation message are handled identically (differing only by the values found in the relevant properties). The confirmation message is permitted not to bind the address:response-address property.
A fault message must always contain the corr:message-id of the message which triggered it as the first value of its own corr:references property.
Following the completion of processing of a Fail state, each node should perform a reset to resume initial state.
Implementation of the confirmation pattern requires implementation of two features, and strongly recommends the implementation of another. All of these features have to do with message addressing and correlation.
When the confirmation pattern is bound to a protocol with synchronous semantics, some properties in the message addressing feature may be defaulted to the endpoints of the currently open socket. However, because the exchange is more complex than request/response, it is not permitted to bind, implicitly or explicitly, the properties of the message correlation feature in this fashion (although it is permitted for most exchanges). In fact, it can be done, it's just very strongly discouraged.
Implementation of the confirmation 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 property must be unique for this conversation, at minimum. The corr:references property may be omitted in a presence message, but it MUST be present in the challenge and confirmation messages, and MUST accumulate the corr:message-id values of the preceding messages in the exchange.
Implicit binding to an endpoint, as is done in the solicit/response and asynchronous request/response message exchange patterns when in the context of a synchronous protocol binding, is discouraged. It does not permit the confirmation message to include the id of the presence message.
The message correlation feature requires no other features. The failure-destination feature requires it.
The message-address feature is required for implementations of the confirmation 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 address valid for the protocol bound, and which the sender is monitoring. In the challenge message, it is typically the well-known address of the service. address:final-destination contains a value representing the target address of the message, as it is known to the sender. For the presence and confirmation messages, this is usually the well-known address of the server. For the challenge message, it is the value supplied in the presence message's address:response-address, or if that is missing, the value of the presence message's address:original-source. Apart from the initial (presence) message, all messages have as final destination the value of the triggering message's response address, and if that is missing, the value of the original source property. The confirmation need not bind a valid value to the address:response-address property.
Message addressing does not require any other feature. It may be used by failure destination, which in the context of this exchange pattern makes use of message addressing properties to set defaults. External features for more complex routing may also make use of its properties, and as a rule should be compatible with it.
The failure-destination feature is optional, but recommended, for services that support the confirmation 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 specifies an algorithm for defaulting the value of the faildest:failure-destination value: first the value of the address:response-address property, then the value of the address:original-source property.
The failure destination feature requires the message correlation feature. Every fault must contain a corr:references property which contains the contents of the triggering message's corr:references property, prepended with the value of the triggering message's corr:message-id property.
It is very tempting to try to describe the confirmation pattern in terms of smaller (one- and two-message) patterns. It is the assertion of the developers of this specification that such a description fails to accurately reflect the operation. That is, this specification avers that the operation concludes only after the third message; it cannot be broken into two separate operations related by some flow control or choreography language. It is an atomic operation, and a basic building block of such choreography or flow languages.
Several examples come to mind. Starting at the bottom of the stack, some of the multicast protocols use an equivalent to double-opt-in to insure against address spoofing when a node joins a multicast group. Slightly higher, but perhaps better known, is the TCP three-way handshake. While it is unlikely that SOAP will be bound to either of these relatively low-level protocols, their example continues up the stack. Well-administered mailing lists use double opt-in, in order to prevent malicious mail-bombers from signing up a victim to dozens or hundreds of lists (each sending many messages a day; this was a common enough prank in its day that most mailing list management software is configured for double opt-in by default now). There are additional examples at the top of the stack as well.
This specification has been developed in order to make the point that a simple, regular set of message exchange patterns may not be a good model of the patterns of usage of the network, which may be said to be built of simple bits, but is not very regular in its employment of those bits. Symmetry is not a network characteristic, in the majority of cases.