© 2001 Microsoft Corporation. All rights reserved.
Note: The W3C-Document-License was granted
This paper describes some of the properties expected of a SOAP based message path model and proposes that such a model expressed as a SOAP header entry would be within the realm of a W3C standardization initiative.
At its core, SOAP is a stateless, one-way message model defined in terms of SOAP senders and SOAP receivers who can send and receive SOAP messages respectively. An important part of the SOAP model is the SOAP composability model that allows for features to be described in two ways: As part of the SOAP protocol binding to the underlying protocol and/or as one or more SOAP headers within the SOAP envelope.
The assumption of this model is that it is flexible and lightweight enough to build more complicated services involving message exchange patterns such as request/response, peer-to-peer interactions, and long lived dialogs. An example of this is the SOAP HTTP binding that provides SOAP with a set of services defined by HTTP including a request/response message exchange pattern. Other examples could involve SOAP headers as well as more complicated message patterns.
An integral part of SOAP is the notion of intermediaries that can act as both senders and receivers. Intermediaries are central to SOAP in that the SOAP message model provides a distributed processing capability in which the SOAP "actor" attribute can be used to indicate which part of a message is intended for a given intermediary. The purpose of targeting is to provide a mechanism for composing and using distributed value added services such as annotation, collaboration, subscription, privacy policies, and caching. By allowing these services to be composed dynamically across network nodes, the model makes it possible to introduce new services for the proliferation of devices and end users' data (see also RK98).
Despite the SOAP targeting model, SOAP does not define a mechanism for indicating the actual SOAP senders and receivers along the SOAP message path or the order in which the senders and receivers are composed. In other words, SOAP does not define a "message path". For example, take the SOAP processors A, B, C, and D. A SOAP message generated by A can indicate which part of a message is for B, C and D. However, it cannot indicate that the intermediaries are to be organized into a message path illustrated in Figure 1.
Figure 1: Example of SOAP message exchange
Here the message goes from A via B via C to D. The SOAP targeting model is in other words a decentralized message-processing concept rather than a mechanism for transferring SOAP messages across the Web.
In order to provide the semantics for actually exchanging messages, SOAP can be bound to application layer protocols such as HTTP and SMTP. Protocols like these typically define their own message path models and message exchange patterns that in general differ from the SOAP message model. As a result they often don't provide a mapping to the SOAP targeting model because SOAP intermediaries cannot be modeled as SMTP relays or HTTP proxies, for example. This means that a single HTTP or SMTP message path can only be used to model a single hop within the SOAP message path and not by itself describe a complete exchange of a SOAP message from A to D.
In order to solve this, it is necessary to define a message path model that is fully compatible with the SOAP message-processing model and which makes it possible to describe the complete exchange of a SOAP message from A to D in Figure 1.
SOAP intermediaries can process and forward SOAP messages on behalf of other SOAP senders. The purpose of a SOAP processing intermediary is to provide a mechanism for allowing SOAP applications to
Intermediary services may be dynamically composed as a function of the message contents and local policies for how to process a message. As services may not be within the same trust domain and the initial sender may not know the local processing policies, it is a requirement that any given message path can be amended with additional intermediaries as the message travels through the message path. That is, there should be no requirement that the complete message path be known at the time it leaves the initial sender.
A SOAP intermediary can in general take on one of two roles: it can be a processing intermediary in which case it deals with the message using the same rules as any other SOAP receiver and/or sender, or it can be an underlying protocol intermediary in which case it doesn't take any part in the SOAP message path other than acting as a relay at the underlying protocol level.
In order to unambiguously determine what processing rules will be invoked by the intermediary, it is a requirement that two roles is explicitly agreed upon either by direct or out of band communication.
As mentioned, SOAP can be used in combination with a variety of underlying protocols. The boundary between SOAP and the underlying protocol is called a protocol binding. Bindings can be nested and the parameters of a binding can be expressed within the SOAP envelope or within the language of the encapsulating protocol. As an example, the HTTP protocol binding describes the next SOAP receiver of the message using the HTTP Request URI.
One of the advantages of SOAP is that it imposes few restrictions on the underlying protocol. The only real requirement is that the underlying protocol has to be able to transfer a complete SOAP message in a lossless manner. However, it is likely that the underlying protocol will impose a set of constraints on SOAP and in particular how it is used. Examples of such restrictions can be the notion of a given message exchange pattern, a specific security or QoS model, the maximum size of the SOAP message, etc. The task of writing a protocol binding is therefore likely to focus on determining the restrictions that the underlying protocol imposes on SOAP rather than vice versa.
Many existing SOAP toolkits currently support a wide array of bindings to underlying protocols including traditional transports like TCP and UDP. As SOAP supports intermediaries it is furthermore possible to imagine that different underlying protocols are used along the message path of a single message.
In order to support such protocols and scenarios, it is a requirement that there is a common model across protocol bindings that can express the SOAP path parameters. A common way to express the SOAP path parameters might be to embed them within the SOAP envelope as a SOAP header entry rather than carrying them outside the envelope in some protocol binding specific manner. The parameters might still have to be reflected in other places depending on the protocol binding but there would be a common mechanism that all protocols bindings could use as a basis for finding those parameters.
The SOAP/1.1 spec contains both the notion of a one-way message as well as a request/response message exchange pattern. The W3C XML Protocol WG requirements go further and require that it should possible to build even more complicated message exchange patterns using a SOAP path model.
A complication of full-duplex communication is that there are many situations in the existing Internet where communicating parties are not directly addressable. This is for example the case for parties behind firewalls and NAT boxes. Furthermore there are cases where the forward path might be different from the reverse path. The reverse path might have to pass through a store and forward intermediary which might not be needed in the forward path, for example.
It is a requirement to a SOAP path model that it supports the notion of half- and full-duplex communications across a variety of network topologies. Especially it is a requirement that the model includes intermediaries and is flexible enough to allow for variations in the message paths for both half-duplex as well as full-duplex message exchange patterns.
An integral part of supporting multiple message exchange patterns is to be able to correlate messages to one another. The correlation can for example be between multiple messages flowing in the same direction on either the forward or the reverse message path or it can be between messages on different message paths. Messages can be correlated in many ways including over time and space and so any correlation model should be able to support an open-ended set of correlation parameters.
With the large number of existing protocol environments already deployed on the Internet, it is likely that SOAP will have to interact with such environments in ways that do not include carrying a SOAP message in those environments.
As an example of a gateway from SOAP into another environment, one can imagine a SOAP to FTP gateway where FTP commands are mapped into a SOAP message. In order to actually talk to the FTP server the calls will have to be expressed in a language understandable by FTP rather than in SOAP. Likewise, data might be generated and exchanged in a protocol environment foreign to SOAP before it actually is mapped into SOAP for further exchange.
It is a requirement to a SOAP based path model that it understands the notion of gateways and that it although it doesn't have to define the mappings to other protocols, understands that both types of gateways will have to take into account proper migration of fault codes across the protocol boundaries.
The following is a very rough idea for what a solution might actually look like. This is by no means showing any of the details that an actual specification would have to define and is intended only as an indicator of the possible direction that one might take.
The example illustrates a potential SOAP "path" header entry that describes the message path illustrated in Figure 1 with the message starting at A going to D via B via C as intermediaries. In addition the message has an id and shows who it is from. It shows a forward path and indicates a reverse path that is being built as the message traverses the forward path. In this case, the empty via in the reverse path is indicating that the reverse path is defined by the protocol binding. The action element carries the intent of the message similarly to the SOAPAction HTTP header field. All endpoints are represented as URIs.
<S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header>
<m:path xmlns:m="http://www.soap.org/path">
<m:action>http://www.im.org/chat</m:action>
<m:to>soap://D.com/some/endpoint</m:to>
<m:forward>
<m:via>soap://B.com</m:via>
<m:via>soap://C.com</m:via>
</m:forwawd>
<m:reverse>
<m:via/>
</m:reverse>
<m:from>mailto:[email protected]</m:from>
<m:id>uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6</m:id>
</m:path>
</S:Header>
<S:Body>
...
</S:Body>
</S:Envelope>