SOAP Version 1.2 Usage Scenarios

8/2/2019 SOAP Version 1.2 Usage Scenarios

1/32

SOAP Version 1.2 Usage Scenarios

W3C Working Group Note 30 July 2003

This version:

http://www.w3.org/TR/2003/NOTE-xmlp-scenarios-20030730

Latest version:

http://www.w3.org/TR/xmlp-scenarios

Previous versions:http://www.w3.org/TR/2002/WD-xmlp-scenarios-20020626

Editor:

John Ibbotson, IBM

Copyright 2003 W3C

(MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software

licensing rules apply.

Abstract

This document describes the SOAP Usage Scenarios and how they may be implemented using

the SOAP 1.2 specification.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents

may supersede this document. The latest status of this document series is maintained at the

W3C.

The WG has decided to discontinue work on SOAP Version 1.2 Usage Scenarios, and on this

document. The WG developed the SOAP Version 1.2 Usage Scenario to help develop SOAP

Version 1.2. The scenarios have served their purpose in this regard, and the WG no longer

intends to work on them.

The most recent changes to this document are: updated links to the Working Group Charter,added a link to the IPR declaration, and publication as a Working Group Note per the W3C

Process Document, Section 7.5.

Comments on this document should be sent to [email protected] (public archive [7]). It is

inappropriate to send discussion email to this address. Any comment should include a reference

to this document

Discussion of this document takes place on the public [email protected] mailing list [6] under

the email communication rules in the XML Protocol Working Group Charter [5].

Patent disclosures relevant to this specification may be found on the Working Group's patent

disclosure page.

This Note has been endorsed by the W3C XML Protocol Working Group, but has not been

reviewed or endorsed by W3C Members.

The XML Protocol Working Group is part of the Web Services Activity.

AP Version 1.2 Usage Scenarios http://www.w3.org/TR/xmlp-scenarios/

32 24.4.2012 11:47


2/32

A list of all W3C technical reports can be found at http://www.w3.org/TR/.

Short Table of Contents

1. Introduction

2. Documentation of Usage Scenarios

3. References

A. Acknowledgements (Non-Normative)

Table of Contents

1. Introduction


2.1 S1 Fire-and-forget to single receiver

2.1.1 Scenario Definition

2.1.2 Description

2.2 S2 Fire-and-forget to multiple receivers

2.2.1 Scenario Definition2.2.2 Description

2.3 S3 Request/Response


2.3.2 Description

2.4 S4 Remote Procedure Call (RPC)


2.4.2 Description

2.5 S5 Request with acknowledgement


2.6 S6 Request with encrypted payload2.6.1 Scenario Definition

2.6.2 Description

2.7 S7 Third party intermediary


2.7.2 Description

2.8 S8 Conversational message exchange2.8.1 Scenario Definition

2.8.2 Description

2.9 S10 Message header and payload encryption


2.9.2 Description

2.10 S11 Communication via multiple intermediaries2.10.1 Scenario Definition

2.10.2 Description

2.11 DS17 Asynchronous messaging


2.11.2 Description

2.12 S19 Sending non-XML data


2.12.2 Description

2.13 S20 Multiple asynchronous responses


2.13.2 Description2.14 S21 Incremental parsing/processing of SOAP messages


2.14.2 Description

2.15 S23 Event notification


32 24.4.2012 11:47


3/32


2.15.2 Description

2.16 DS24 Caching


2.16.2 Description

2.17 S805 Routing


2.17.2 Description

2.18 S807 Tracking2.18.1 Scenario Definition

2.18.2 Description

2.19 S809 Caching with expiration


2.19.2 Description

2.20 S810 Quality of service


3. References

3.1 Informative References

Appendix


1. Introduction

Introduction to the SOAP usage scenarios.


2.1 S1 Fire-and-forget to single receiver


A sender wishes to send an unacknowledged message to a single receiver (e.g. send a stock

price update every 15 minutes).

2.1.2 Description


32 24.4.2012 11:47


4/32

A fire-and-forget feature in scenario S1 requires a mechanism to send a message to a single

SOAP Receiver and is illustrated in Figure 1. The SOAP Sender does not require any statusinformation that the message has been sent to or received by the recipient. The underlying

transport protocol may implement a response mechanism, but status on whether the message

was successfully sent or otherwise is not returned to the sending SOAP Processor.

Example 1: Fire-and-forget SOAP message

BigCo

34.5

2.2 S2 Fire-and-forget to multiple receivers


A sender wishes to send unacknowledged messages to a set of receivers (e.g. send a stock

price update every 15 minutes).

2.2.2 Description


32 24.4.2012 11:47


5/32

Scenario S2 extends S1 to implement a fire-and-forget feature to multiple SOAP Receivers and

is illustrated in Figure 2. This requires a mechanism to deliver the same message to multipleSOAP Receivers. The delivery of the messages could be implemented using multicast

distribution technology if the underlying transport layer supports this. An alternative

implementation may use repeated applications of scenario S1 with a distribution list of intended

recipients.

2.3 S3 Request/Response


Two parties wish to conduct electronic business by the exchange of business documents. The

sending party packages one or more documents into a request message, which is then sent to

the receiving party. The receiving party then processes the message contents and responds to

the sending party. Examples of the sending party's documents may be purchase order requests,

manufacturing information and patient healthcare information. Examples of the receiving party'sresponses may include order confirmations, change control information and contractual

acknowledgements.

2.3.2 Description

Scenario S3 requires a request/response message feature. A request containing some business

document is sent by a SOAP Sender to a SOAP Receiver where some business application is

invoked. The business application processes the request and generates a response, which isreturned to the SOAP Sender that originated the request. Two alternative solutions are described

which depend upon the characteristics of the underlying transport layer. In either case, the SOAP

Sender is informed of the status (successful or otherwise) of the request message delivery.


32 24.4.2012 11:47


6/32

If the underlying transport protocol supports the correlation of a request and its matching

response directly, then the solution illustrated in Figure 3 may be appropriate. An example ofsuch an underlying transport protocol would be a synchronous HTTP POST. This implementation

would make use of the transport binding proposed in other XML Protocol WG documents. The

business document sent as a request by the SOAP Sender would be inserted as the payload of

the request message. Following the receipt of the request, the processing application would

generate a document which would be returned as the payload of the response message with

appropiate status codes. If for whatever reason, the request message was not received orprocessed by the intended business application, suitable status messages would be generated

by the underlying transport layer and reported to the SOAP Sender.


32 24.4.2012 11:47


7/32

If the underlying transport protocol does not support a request/response model, then the

configuration shown in Figure 4 may be appropriate. Examples of such an underlying protocol

may include unidirectional queuing middleware. In this case, message identification and

correlation is provided by SOAP Headers. In the request SOAP message, a Message Identifier

Handler is responsible for generating a unique message identifier and inserting it into a SOAP

Header. This forms part of the SOAP request message and is sent from SOAP Application 1 to

the receiving SOAP Application 2. The request message is processed by a business application

and a response message is assembled. This includes a SOAP Header built by a Message

Correlation Handler which links the response message to its associated request.

Example 2: SOAP request message containing a message identifier

uuid:09233523-345b-4351-b623-5dsf35sgs5d6

........

Example 3: SOAP response message containing correlation to original request

uuid:09233523-567b-2891-b623-9dke28yod7m9

uuid:09233523-345b-4351-b623-5dsf35sgs5d6

........

2.4 S4 Remote Procedure Call (RPC)


The sender invokes the service by passing parameters that are serialized into a message for

transmission to the receiving server.

2.4.2 Description

Scenario S4 differs from scenario S3 in that the request message consists of a set of serialized

parameters used to invoke some remote procedure which responds with a set of results. This is

a different programming model to the document exchange one illustrated by scenario S3.

Scenario S4 requires a request/response mechanism as in S3, with the parameter and result

serialization needed for the RPC programming model form the SOAP Body element.


32 24.4.2012 11:47


8/32

Figure 5 illustrates an RPC invocation over an underlying transport protocol such as HTTP that

supports request/response. In this case, no additional headers are needed to correlate therequest and response messages. Example request and response SOAP messages are:

Example 4: SOAP RPC request message

DEF

Example 5: SOAP RPC response message


9/32

In Figure 6, the underlying transport protocol does not support request/response directly. The

RPC request and response elements again form the Body of the SOAP messages. Correlation ofthe request and response is provided by the Message Identifier and Message Correlation

handlers as described in scenario S3.

Example 6: SOAP RPC request message with message identification

uuid:09233523-345b-4351-b623-5dsf35sgs5d6

DEF

Example 7: SOAP RPC response message containing correlation to original request

uuid:09233523-567b-2891-b623-9dke28yod7m9

uuid:09233523-345b-4351-b623-5dsf35sgs5d6


10/32

2.5 S5 Request with acknowledgement


A sender wishes to reliably exchange data with a receiver. It wishes to be notified of the status of

the data delivery to the receiver. The status may take the form of:

The data has been successfully delivered to the receiver, or1.

Some failure has occurred which prevents the successful delivery to the receiver.2.

2.5.2 Description

Figure 7 illustrates a request/response scenario with the SOAP Sender requesting status

information from the matching SOAP Receiver. This status may provide delivery information to

the sender in addition to other business related responses that the receiving application may

generate. Figure 7 assumes that the underlying transport protocol supports the request/response

exchange model. A Status Handler is registered with the SOAP Sender and configured to

request the status information. A matching handler on the SOAP Receiver generates therequested status information and places it in the response message which is then returned to the

originating SOAP Sender.

In the example SOAP messages below, a StatusRequest header element includes an identifier

for the message being sent. The inclusion of the StatusRequest header results in the receiving

SOAP processor including a StatusResponse Header in the response. This includes information

about the delivered message including an enumerated status and timestamp.

Example 8: SOAP request message with staus request header

uuid:09233523-345b-4351-b623-5dsf35sgs5d6


f 32 24.4.2012 11:47


11/32

-----

Example 9: SOAP response message containing delivery status for request

uuid:09233523-567b-2891-b623-9dke28yod7m9

DELIVERED

2001-03-09T12:22:30Z

-----

2.6 S6 Request with encrypted payload


A sender wishes to exchange data with a receiver and has agreed to encrypt the payload. The

sending and receiving applications agree on the encryption methodology. Data is encrypted by

the originating application and sent to the receiver via SOAP. The data reaches the receiving

application untouched, and may then be decrypted in the agreed-upon manner.

2.6.2 Description

Scenario S6 describes two applications that wish to share encrypted data as an opaque body in

a SOAP message. It places no requirements on the SOAP messaging layer. Figure 8 illustrates

this scenario.

Example 10: Plaintext SOAP message


f 32 24.4.2012 11:47


12/32

IBM

The following is the encrypted version of the above plain SOAP message. The body entry is encrypted using a symmetric key identified by the key name

"Symmetric Key" and replaced by the element with an id "encrypted-

body-entry". A header entry for this encrypted data is added to the SOAPheader. Note that the element in the header entry has a reference to

the element. The symmetric key used for encryption is stored in the

element in the header entry in an encrypted form, that is, it is encrypted by

John Smith's RSA public key.

Example 11: Encrypted SOAP message

John Smith's RSA Key

ENCRYPTED 3DES KEY......


13/32

their requirements to the marketplace hub, which broadcasts this information to multiple

suppliers. Suppliers respond to the marketplace hub where the information is logged and

ultimately delivered to the buyer.

2.7.2 Description

Figure 9 illustrates an infrastructure where SOAP based messaging is used to support a third

party marketplace acting as an intermediary between buyers and sellers. The market place

business model involves the recruitment of multiple suppliers for goods and services. Buyers

may then connect to the marketplace and take advantage of the services they provide. Themarketplace acts as a channel for the commercial transactions between a buyer and its chosen

seller. A marketplace can exist to serve both B2B and B2C transactions.

In scenario S7, the marketplace acts as a blind intermediary. A buyer connects to the

marketplace and places an order for items or services it requires. The buyer may be as simple as

a browser or as complex as a procurement application. Once the marketplace has received the

buyers order, it contacts an appropriate set of sellers who then provide competitive bids aginst

the order. The marketplace can then select the most attractive bid and connect the winning seller

to the buyer. A purchasing process is then initiated with the marketplace acting as anintermediary in the transaction.

From a SOAP messaging point of view, the scenario illustrated in Figure 9 consists of a set ofrequest/response messages between the buyer and the marketplace resulting in the buyers

order being registered. Once received, the marketplace then contacts its set of selected sellers

again by a set of request/response messages. Design decisions made during the implementation

of the marketplace software will determine whether supplier messages are sent from a single

SOAP Sender to multiple SOAP Receivers, one at each of the sellers sites. Alternatively, a

SOAP Sender could be instantiated for each supplier and a physical 1:1 relationship established.

Prior agreements on message qualities such as reliability, security and structure would be put in

place between the marketplace and its sellers. These qualities would define what additional

SOAP Handlers were needed for the message exchange patterns between the marketplace and

sellers.

2.8 S8 Conversational message exchange


f 32 24.4.2012 11:47


14/32


Two partners are engaged in a long-running process, which involves multiple message

exchanges. Examples of such processes may be complex supply chain management, dynamic

manufacturing scheduling or information retrieval. There may be multiple instances of the same

process in progress between the same two partners.

2.8.2 Description

Interactions between business partners are usually more complex than a singlerequest/response message exchange. A long running set of message exchanges may, for

example be used to implement a business interaction such as procurement of goods or services.

In this case there are advantages in grouping individual messages into a longer running set of

exchanges. Such an exchange of messages is known as a conversation. Conversations may

continue between a pair of trading partners for a long time. Completion of a conversation

instance may take days, weeks or months.

A conversation between two trading partners may be defined by shared configuration information

such as an ebXML Trading Partner Agreement (TPA). A TPA includes information such asexpected response times, business process actions that each party undertakes to complete,security information and message content structures. In a procurement process, an example

conversation may be:

A buyer request a quotation for some goods, the seller responds with the quote.1.

The buyer places a puchase order which the seller accepts.2.

The seller informs the buyer of delivery dates, the buyer accepts.3.

The buyer acknowledges delivery of the goods, the seller acknowledges.4.

The buyer provides payment, the seller issue a receipt.5.

All of the example message exchanges are related an instance of the TPA between the two

partners. For a message to be valid as part of the agreed rules, each partner has to check


f 32 24.4.2012 11:47


15/32

whether the current message is valid within the scope of the TPA.

Figure 10 illustrates how this scenario could be implemented. Each partners SOAP processor

has access to a database which is configured by the TPA agreed between the two partners. A

Conversation State Handler in the SOAP Sender configures its SOAP Block with information that

identifies a message with conversation instance it is part of. A matching handler in the SOAP

Receiver uses the senders information to test whether the received message is acceptable

within the rules of the TPA. It does this by checking with its own rules database where the state

information on each of the conversation instances currently active is stored. If a messageviolates the rules of the TPA, then the application can raise a fault condition.

Note that Figure 10 does not include handlers for other message headers to support reliability orsecurity which may be required under the agreed TPA.

In the following request and response examples, a ConversationState Header is used to identify

which agreement governs the exchange between the two trading partners (AgreementId). To

support multiple concurrent conversations under the same agreement, a ConversationId element

is included. The values of AgreementId and ConversationId will remain constant for the lifetime of

a particular conversational exchange and will appear in both request and response messages.

Example 12: SOAP request message as part of a conversational exchange

uuid:09233523-345b-4351-b623-5dsf35sgs5d6

uuid:02957815-38fh-39gp-0dj2-dm20fusy1n5j

-----

Example 13: SOAP response message as part of a conversational exchange

uuid:09233523-345b-4351-b623-5dsf35sgs5d6

uuid:02957815-38fh-39gp-0dj2-dm20fusy1n5j

-----

2.9 S10 Message header and payload encryption


Two trading partners engaged in a message exchange may agree to cryptographically sign and

verify either the message header, the routing header(s) and/ or the payload. The sender or

originating application may perform the signing of the payload. The sending message handler

signs the message header. A routing header may be appended to the message header. The

routing header may also be signed by a message service handler.

2.9.2 Description


f 32 24.4.2012 11:47


16/32

In scenario S6, two applications communicated using encrypted payloads. These opaque

payloads had no impact on the SOAP processing layer. In this scenario, the action of signingand/or encrypting the headers or payload is the responsibility of the SOAP processing layer.

Figure 11 illustrates how the encryption agreements are accessible to a Message Signing

Handler on the SOAP Sender and a matching Message Verification Handler on the SOAP

Receiver. An additional Message Routing Header may also be part of the SOAP message. This

header may also be signed and verified if needed by the security requirements of the message

exchange.

2.10 S11 Communication via multiple intermediaries


An intermediary forwards a message to the ultimate receiver on behalf of an initial sender. The

initial sender wishes to enforce the non-repudiation property of the route. Any intermediate

message service handler that appends a routing message must log the routing headerinformation. Signed routing headers and the message readers must be logged at the message

handler which passes the message to the ultimate receiver to provide the evidence of

non-repudiation.

2.10.2 Description


f 32 24.4.2012 11:47


17/32

Scenario S11 requires an audit chain to be created between a SOAP Sender that originates the

message and the ultimate SOAP Receiver including any SOAP Intermediaries that the messagepasses through. Figure 12 illustrates a possible implementation of this scenario. Each SOAP

Node on the message path has access to a persistent store (typically a database) that can be

used to store an audit record for each message. A Routing Logging Handler on each SOAP

Node has the responsibility of logging each message in the persistent store. A further

responsibility of the handler is to sign the message routing header before passing the message

on to the next SOAP Node in the path. Support for certificates and other artifacts required forsigning a message are not shown.

2.11 DS17 Asynchronous messaging


A sender sends a message asynchronously to a receiver expecting some response at a later

time. The sender tags the request with an identifier allowing the response to be correlated withthe originating request. The sender may also tag the message with an identifier for another

service (other than the originating sender) which will be the recipient of the response.

2.11.2 Description


f 32 24.4.2012 11:47


18/32

Scenario DS17 is the same as the basic request/response pattern described in scenario S3. The

difference is that the request and response messages are separated in time and implemented astwo unidirectional messages. The sending SOAP Application does not block and wait for the

response to return. The sending SOAP Application is notified when a response is received by its

SOAP Receiver. It then uses the correlation information within the received message to match

the response to a message it sent some time earlier.

Figure 11 illustrates a possible implementation. In the request SOAP message, a MessageIdentifier Handler is responsible for generating a unique message identifier and inserting it into a

SOAP Header. This forms part of the SOAP request message and is sent from SOAP Application

1 to the receiving SOAP Application 2. The request message is processed by a business

application and a response message is assembled. This includes a SOAP Header built by aMessage Correlation Handler which links the response message to its associated request.

Example 14: SOAP asynchronous request message containing a message identifier

uuid:09233523-345b-4351-b623-5dsf35sgs5d6

........

Example 15: SOAP asynchronous response message containing correlation to original request

uuid:09233523-567b-2891-b623-9dke28yod7m9uuid:09233523-345b-4351-b623-5dsf35sgs5d6

........


f 32 24.4.2012 11:47


19/32

2.12 S19 Sending non-XML data


A digital camera wishes to transmit image data over a wireless link using SOAP to a remote

server. The binary image data (non-XML) accompanies the message. The digital camera

represents a situation in which connections from the receiver to the sender may not be permitteddue to device limitations or firewalls.

2.12.2 Description

Support for non-XML data has been described elsewhere. The SOAP with Attachments [2] note

to the W3C has been adopted by the ebXML Message Services specification [1] as the basis for

defining a message structure which can support non-XML data. Supporting non-XML data

requires additional packaging of the message which can be provided by a MIME multipartstructure and impacts the binding of a message to its underlying transport protocol. Figure 14

illustrates a unidirectional SOAP message path. A Message Manifest Handler is implementedwhich creates a set of references to the different parts of a multipart MIME package. Each part is

referenced by its content identifier.


f 32 24.4.2012 11:47


20/32

Figure 15 illustrates how different parts of a message are packaged using MIME multipart. The

outermost MIME envelope packages a set of individual MIME parts. The first MIME part containsa SOAP message which includes the Manifest Header block created by the Message Manifest

Handler. The second and subsequent MIME parts contain payload(s) which may be XML

documents or any other MIME content type such as image, audio or video data. The SOAP

manifest header can contain elements that reference the separate MIME parts using their

content identifiers. This may be achieved using XLink references as shown in the following

example. The XLink role attribute may be used to further qualify the type of data contained withinthe payload.

Example 16: SOAP message containing a manifest for non-XML data

My first holiday photograph

My second holiday photograph

........

2.13 S20 Multiple asynchronous responses


An application requests some information from a server, which is returned at a later time in


f 32 24.4.2012 11:47


21/32

multiple responses. This can be because the requested information was not available all at once

(e.g., distributed web searches).

2.13.2 Description

Scenario S20 is an extension of scenario DS17 - asynchronous messaging. Instead of a single

response message, more than one can be sent by the receiving application to the originator. A

simple architecture would be the same as DS17 with multiple responses received by the

originating application and corelated to the original request by a Message Correlation Handler.

Figure 15 illustrates an extension to this using a Sequence Handler. The Sequence Handlerensures that a unique sequence number is added to each response message. If the responding

application knows in advance that there will be a fixed number of multiple responses, then the

Sequence Handler may use an N of M format to indicate how many response messages are to

be expected.

Example 17: SOAP request message containing a message identifier

uuid:09233523-345b-4351-b623-5dsf35sgs5d6

........

Example 18: First SOAP response message containing sequencing and correlation to original

request

uuid:09233523-567b-2891-b623-9dke28yod7m9


f 32 24.4.2012 11:47


22/32

uuid:09233523-345b-4351-b623-5dsf35sgs5d6

1

5

........

Example 19: Final SOAP response message containing sequencing and correlation to original

request

uuid:40195729-sj20-pso3-1092-p20dj28rk104

uuid:09233523-345b-4351-b623-5dsf35sgs5d6

5

5

........

2.14 S21 Incremental parsing/processing of SOAP messages


An SOAP sender generates a lengthy SOAP message that is incrementally transmitted and

received by a SOAP receiver. The SOAP receiver employs a SOAP handler that can

incrementally process the body as it is received (e.g., employing a SAX-style XML parser on the

body as it arrives). Note that the entire message need not be present at one time at any point in

its existence.

This would be particularly helpful for memory-limited processors. It is also very efficient for

services which are consistent with incremental, real-time transformations of the data, directarchiving of received data, etc. It would also be useful in scenarios in which voluminous body

data can be directly transduced into application data structures or events by a SOAP (module)

processor. In particular, there is no need for the explicit construction of a DOM model of the data.Support for various data models might still be possible even with incremental processing if the

models are incrementally constructible.

2.14.2 Description

Scenario S21 requires the incremental parsing and processing of a SOAP message by a

receiver. This is a general scenario with memory-limited processor requirements forming a

subset of the scenario. If the SOAP Body contains a large amount of data, then it may be

processed incrementally by a SAX parser if the data is chunked as in the following example. The

SAX parser will have a handler triggered by the BodyDataChunk element.

Example 20: Final SOAP response message containing sequencing and correlation to original

request


f 32 24.4.2012 11:47


23/32

1024

kfkk34jkhfSomeBase64EncodedDatajdsgkjgjajgo34093589uvsjv.....jhfjhf350giqh

1024

oqjrj45cmoLastLotOfBase64EncodedData12r9vnhofjhckzlmxjws.....skfjk23ogkkjh

If a SOAP request is being streamed and processed incrementally, then the matching response

message may be streamed to the original sender. In this case, the design of the receiving

application is critical with respect to timing and error handling.

If errors are generated by the SOAP request Headers, then a SOAP Fault is inserted in the

response and processing of the request message is terminated.

1.

The SOAP receiving application may treat each BodyDataChunk element as atomic. A

positive or negative acknowledgement is streamed to the SOAP response depending on

whether the BodyDataChunk element was successfully processed or not. The SOAP

response message is terminated once the end of the SOAP request is reached.

2.

Alternatively, the SOAP receiving application may process each BodyDataChunk until

either the end of the SOAP request is received or a fault occurs. In the case of a fault, a

SOAP Body fault element is streamed to the SOAP response and processing of the SOAP

request is terminated.

3.

2.15 S23 Event notification


An application subscribes to notifications of certain named events from an event source. When

such events occur, notifications are sent back to the originating application (first party notification)

or to another application (third party notification). For example, an application can subscribe to

notification of various aspects of a printer's status (e.g., running out of paper, ink etc.). Thenotifications of such events could be delivered to a management application.

2.15.2 Description


f 32 24.4.2012 11:47


24/32

Scenario S23 describes event notification using a publish subscribe mechanism. An

implementation of this scenario uses an example of the request/response scenario S3 to registera subscription and fire-and-forget to multiple receivers scenario S2 for the notification. Figure 17

illustrates how a request/response message pattern can be used with a Subscription Request

Handler to register an interest (or subscription) in some set of events. The registration is made

with some subscription service. The success or otherwise of the registration is returned to the

subscribing application using a Subscription Ack Handler which provides an acknowledgement to

the subscribing application.

Delivery of an event noification to a set of subscribers may be implemented using the fire-and-

forget to multiple receivers scenario S2. The subscription service provides the list of valid

applications that have registered an interested in a particular event. This list may then beconverted into a group address or distribution list to support the implementation of the fire-and-

forget scenario.

A subscription request may include a list of events within the SOAP Body as in the following

example.In this example, a subscription is registered with a stock price notification service. The

subscribing application will be informed of company BigCos stock price, volume traded and time

whenever the price is greater than 100.

Example 21: SOAP event subscription request message

PRICE

VOLUME

TIMESTAMP

BigCo

100

An acknowledgement may include an identifier to the subscription as in the following example:


f 32 24.4.2012 11:47


25/32

Example 22: SOAP event subscription acknowledgement response

uuid:40195729-sj20-pso3-1092-p20dj28rk104

The identification may be used in subsequent notifications to the application as a result of the

subscription:

Example 23: SOAP event notification

uuid:40195729-sj20-pso3-1092-p20dj28rk104

BigCo

100.56

1023452001-03-09T12:22:30Z

2.16 DS24 Caching


Some applications may wish to make caching possible for latency, bandwidth use or other gains

in efficiency. To enable this, it should be possible to assign cacheability in a variety of

circumstances. For example, "read" caching might be used to store messages at intermediaries

for reuse in the response phase of the request/response message exchange pattern. Such

caching might be on the scope of an entire message, a SOAP module, or scoped to individual

SOAP module elements.

Similarly, "write" caching may be useful in situations when a request message in a

request/response message exchange pattern (as well as similar messages in other message

exchange patterns) does not need to be immediately forwarded or responded to. Such

cachability might be scoped by different methods, as outlined above.

Cacheability scoped by different elements might be associated by an attribute to the target

element, through use of XML Query or XPath to describe the target elements in a header, orimplied by the document schema, for example.

Cacheability mechanisms applied to messages, bodies or elements might include time-to-live

(delta time), expiry (absolute time), entity validation, temporal validation, subscription to

invalidation services, and object update/purge.

Finally, some applications may be capable of describing the dependencies and relationships

between message elements. For example, a response element may be applicable to a wide

range of requests; it would be beneficial to describe this element's relationship with request

elements, so that it may satisfy a wide range of requests in an economical fashion. Similarly, thepresence of a particular element may be a trigger for a cacheability mechanism to be applied to

another element, such as validation or invalidation.

2.16.2 Description

Caching is frequently used as an optimization in distributed systems. It can be used to avoid


f 32 24.4.2012 11:47


26/32

re-doing computations or complex database access when the results remain valid for an

extended period of time. In this case, subsequent requests for the same information can be

served with the cached version rather than repeat the processing with the associated overheads.

Another use of caching is in the transmission of data where copies may be held at leaf servers

for local service provision rather than repeatedly access a central information repository. This has

the combined effect of providing faster access to the information, reducing network bandwidth

requirements and reducing the workload on a central server. Caching may be provided as part of

an underlying transport infrastructure but in the case of this scenario, it is assumed that the

caching is independent of any underlying transport.

An example of this kind of scenario is the caching of the response to a request in situations

where a subsequent request can be safely answered with the same result. This example

coincides with scenario S809 (Caching with expiry) where a catalog is updated at 8am each

morning. Once the catalog has been updated, all price queries against it are valid until 8am the

following day. If a price query request is repeated against the same item, then a cached

response can be returned to the SOAP Sender otherwise the request is forwarded to the catalog

server and its response is cached. All entries in the cache are purged at the time of the updated

catalog being available. Figure 18 illustrates a possible architecture.

SOAP Application 1 initiates a request for catalog price information illustrated in the following

example.

Example 24: SOAP request message for catalog price information

ABC-1234

The caching intermediary SOAP Application 2 is unable to fulfil the request from its local store so

it forward the request which ultimately arrives at the catalog server SOAP Application 3. The

catalog server process the request and assembles a response message containing the


f 32 24.4.2012 11:47


27/32

requested price information. An additional SOAP Header is placed in the response to control any

caches that may exist in the return path. The CacheControl Header contains a CacheKey which

allows matching of future requests to the cached response together with an Expires element that

sets the time the local copy must be purged. This response is returned via the caching

intermediary.

Example 25: SOAP response with caching header received by intermediary

ABC-1234

2001-03-09T08:00:00Z

ABC-1234

120.37

At the caching intermediary, the CacheControl header information is used to make a local copy of

the response message, keyed by the CacheKey. The copy will be purged at the time specified by

the Expires element. The CacheControl header element is removed by the intermediary and the

catalog price information is returned to the original sender. The request/response path for this

message is the complete roundtrip between the original SOAP Sender and SOAP Receiver and

is shown by Message Path 1 in Figure 18.

Example 26: SOAP response with received by original Sender

ABC-1234

120.37

Since there is now a local copy of the price information for item ABC-1234 in the intermediary

cache, subsequent requests for price information can be fulfilled by the intermediary. This is the

shorter request/response path Message Path 2.

2.17 S805 Routing


A developer wishes to force an explicit message path through certain intermediaries - for

instance, he might use an anonymizing intermediary to make a call to a specified remote servicewithout allowing the target service to track the identity/IP of the caller. In this case, the

intermediary is responsible for calling the target service and returning the results to the caller,

using its own authentication credentials if any are required by the target service.

2.17.2 Description

This scenario has been addressed in detail by the WS-Routing [4] (formerly SOAP-RP)

specification.

2.18 S807 Tracking


f 32 24.4.2012 11:47


28/32


A service provider wishes to track incoming messages to see exactly which processing

intermediaries have touched it by the time it arrives at its destination. It therefore requires a

tracking extension to be included by all clients, and by any processing intermediaries along the

message paths from the clients to the server.

2.18.2 Description

Scenario S805 describes a routing requirement whch is addressed in detail by the WS-Routing[4] (formerly SOAP-RP) specification. This describes how a message may be reouted through

some messaging infrastructure. Once the message has arrived at its ultimate receiver, the route

the message has taken may be required for auditing purposes. A track of the message path may

be created by adding a tracking header to the message in addition to any routing information.

This is illustrated in the following example. A routing header has been added to the message in

accordance with WS-Routing [4]. A TrackingHeader is used to maintain a list of Intermediary

names and associated Timestamp elements. As the message passes through each intermediary,

a Tracking Handler appends a Via element to the TrackingHeader. The Via element contains thename of the intermediary together with the date/time the message arrived or was forwarded bythe intermediary. The list of Via elements therefore forms the audit trail for the message.

Example 27: SOAP request with routing and tracking headers

soap://A.com/some/endpoint

2001-03-09T08:00:00Z

soap://B.com

2001-03-09T08:01:00Z

soap://C.com


f 32 24.4.2012 11:47


29/32

2001-03-09T08:02:00Z

soap://D.com/some/endpoint

2001-03-09T08:03:00Z

http://www.im.org/chat

soap://D.com/some/endpoint

soap://B.com

soap://C.com

soap://A.com/some/endpoint

uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6

.....

2.19 S809 Caching with expiration


BizCo updates their online price catalog every morning at 8AM. Therefore, when remote clients

access their SOAP inventory service, clients and intermediaries may cache the results of any

price queries until 8AM the next day.

2.19.2 Description

See description for DS24.

2.20 S810 Quality of service


A SOAP sender (not necessarily the initial SOAP sender) wants the SOAP message to be

handled with specific quality of service as it traverses the SOAP message path to include

multiple SOAP Processing intermediaries. Information in the SOAP message is used to select

appropriate QoS mechanisms (e.g., RSVP, Diffserv, MPLS, etc.). Selection of QoS may be

constrained by QoS policies, Service Level Agreements (SLAs), Service Level Specifications

(SLS).

2.20.2 Description

A SOAP header block is one possible approach to implementing this scenario. The SOAP 1.2

specification does not define this hypothetical SOAP Quality Of Service (QoS) block. An initial

SOAP sender sends a SOAP message containing a QoS header block through one or more

SOAP intermediaries to an ultimate SOAP receiver. The intermediary is targeted by the initialSOAP sender from within the SOAP message by inserting a role attribute within the QoS Block to

be used at the SOAP intermediary as described in the SOAP processing model (Part 1, section

2.5). The SOAP specifications do not state how the role attribute is to be used by the SOAP

sender. Potentially, it can be used in the context of the SOAP binding framework to provide a hint

for message routing. However, message routing is not within the scope of the SOAP 1.2specifications. The SOAP intermediary must examine the SOAP QoS Block, and determine how

to invoke the QoS capabilities exposed via the SOAP binding. If the SOAP QoS Block is markedmustUnderstand, then the intermediary is expected to be QoS-aware. If it is not QoS-aware, then

a SOAP fault is generated, as this mandatory header cannot be processed. If it is QoS-aware,


f 32 24.4.2012 11:47


30/32

but cannot honor the specific QoS parameters carried in the QoS Block, then any fault or other

response to the sender or elsewhere (e.g., log file) is not defined in the SOAP specifications. The

specification of the QoS extension, when defined, would need to describe error handling,

negotiations, or other processing under all circumstances.

If the intermediary is QoS-aware, then presumably the information in the QoS Block is used

when forwarding the SOAP message further along on its message path toward the ultimate

SOAP receiver. In addition to the use of SOAP Blocks to extend the functionality of SOAP, this

scenario may also require extensions to the HTTP binding, or a completely new binding. TheBinding Framework allows for additional properties, outside the SOAP envelope, that may berequired to invoke the lower layer QoS mechanisms. Additional properties (within the Binding

Framework) may be required. For sake of discussion, lets assume that the SOAP node will send

the SOAP message using HTTP, but traffic classification of this HTTP flow would be done using

diffserv so particular per-hop behaviors can be used within the network en-route to the next

SOAP node. Traffic classification for diffserv can be done by the SOAP node sending the SOAP

message, or by network devices (assuming they know how to recognize the particular HTTP

flow). If traffic classification is handled by a network device, perhaps communications would be

needed between the SOAP node and the network device, for example, to provide the networkdevice with the TCP/IP port numbers and IP addresses of the HTTP connection. This would

presume some way to obtain this port and address information, which probably involves an API

or properties that are beyond the scope of the SOAP 1.2 specifications.

For example, to state that a separate spec can define properties in accordance with the binding

framework to extend the capability of the HTTP binding (or any other binding). In the case of

SOAP RPC, a QoS extension at the ultimate SOAP receiver may attempt to insert a QoS Block

in RPC response. The RPC response may succeed, but perhaps the desired QoS cannot be

delivered on the return message path. It is not clear if a SOAP fault should be generated.

Likewise, if a SOAP Intermediary on the return message path cannot honor the QoS Block

(assumed to be marked mustUnderstand), is it permissible to convert the SOAP RPC response

to a SOAP fault? A SOAP extension in the initial SOAP sender is needed to insert this SOAP

QoS Block. The sender may need to use properties as defined by the SOAP binding framework

to communicate QoS parameters to be used by the underlying network. Since a SOAP bindingmust define the rules for how the data is exchanged using the underlying protocol, a custom or

supplemental binding may be required to support this QoS usage scenario. The HTTP binding

described in the SOAP 1.2 specification does not explicitly support QoS properties. The SOAP

1.2 specification does not preclude extensions to this HTTP binding, which would provide thecapability to define either QoS properties or a requirement to examine the SOAP envelope (i.e.,

SOAP QoS Block) to determine the QoS used for transmission. Alternatively, a completely new

binding can be specified that includes QoS explicitly, rather than as an extension to an existing

binding

3. References

3.1 Informative References

[1]

Message Service Specification, ebXML TRP Version 1.0 (See http://www.ebxml.org/specs

/ebMS.pdf.)

[2]

SOAP Messages with Attachments (See http://www.w3.org/TR/SOAP-attachments.)

[3]XML Protocol (SOAP) Requirements (See http://www.w3.org/TR/2001/WD-xmlp-

reqs-20010319/#N2082.)

[4] Web Services Routing Protocol (WS-Routing) (See http://msdn.microsoft.com/library

/default.asp?url=/library/en-us/dnsrvspev/html/ws-routing.asp.)

[5]XML Protocol Charter (See http://www.w3.org/2002/10/XML-Protocol-Charter.)


f 32 24.4.2012 11:47


31/32

[6]

XML Protocol Discussion Archive (See http://lists.w3.org/Archives/Public/xml-dist-app/.)

[7]

XML Protocol Comments Archive (See http://lists.w3.org/Archives/Public/xmlp-comments/.)


This specification is the work of the W3C XML Protocol Working Group.

Members of the Working Group are (at the time of writing, and in alphabetical order): Carine

Bournez (W3C), David Fallside (IBM), Tony Graham (Sun Microsystems), Martin Gudgin

(Microsoft Corporation, formerly of DevelopMentor), Marc Hadley (Sun Microsystems), Gerd

Hoelzing (SAP AG), Oisin Hurley (IONA Technologies), John Ibbotson (IBM), Kazunori Iwasa

(Fujitsu Limited), Mario Jeckle (DaimlerChrysler R. & Tech), Mark Jones (AT&T), Anish

Karmarkar (Oracle), Jacek Kopecky (Systinet/Idoox), Yves Lafon (W3C), Michah Lerner (AT&T),

Noah Mendelsohn (IBM, formerly of Lotus Development), Jeff Mischkinsky (Oracle), Nilo Mitra(Ericsson), Jean-Jacques Moreau (Canon), Masahiko Narita (Fujitsu Limited), Eric Newcomer

(IONA Technologies), Mark Nottingham (BEA Systems, formerly of Akamai Technologies), David

Orchard (BEA Systems, formerly of Jamcracker), Andreas Riegg (DaimlerChrysler R. & Tech),

Herv Ruellan (Canon), Jeff Schlimmer (Microsoft Corporation), Miroslav Simek (Systinet/Idoox),Pete Wenzel (SeeBeyond), Volker Wiechers (SAP AG).

Previous members were: Yasser alSafadi (Philips Research), Bill Anderson (Xerox), Vidur

Apparao (Netscape), Camilo Arbelaez (WebMethods), Mark Baker (Idokorro Mobile (Planetfred),

formerly of Sun Microsystems), Philippe Bedu (EDF (Electricit de France)), Olivier Boudeville

(EDF (Electricit de France)), Don Box (Microsoft Corporation, formerly of DevelopMentor), TomBreuel (Xerox), Dick Brooks (Group 8760), Winston Bumpus (Novell), David Burdett (Commerce

One), Charles Campbell (Informix Software), Alex Ceponkus (Bowstreet), Michael Champion

(Software AG), David Chappell (Sonic Software), Miles Chaston (Epicentric), David Clay

(Oracle), David Cleary (Progress Software), Conleth O'Connell (Vignette), Ugo Corda (Xerox),

Paul Cotton (Microsoft Corporation), Fransisco Cubera (IBM), Jim d'Augustine (eXcelon), Ron

Daniel (Interwoven), Glen Daniels (Macromedia, formerly of Allaire), Dug Davis (IBM), RayDenenberg (Library of Congress), Paul Denning (MITRE), Frank DeRose (Tibco), Mike Dierken

(DataChannel), Andrew Eisenberg (Progress Software), Brian Eisenberg (DataChannel), ColleenEvans (Sonic Software), John Evdemon (XMLSolutions), David Ezell (Hewlett-Packard), Eric

Fedok (Active Data Exchange), Chris Ferris (Sun Microsystems), Daniela Florescu (Propel), Dan

Frantz (BEA Systems), Michael Freeman (Engenia Software), Dietmar Gaertner (Software AG),

Scott Golubock (Epicentric), Rich Greenfield (Library of Congress), Hugo Haas (W3C), Mark

Hale (Interwoven), Randy Hall (Intel), Bjoern Heckel (Epicentric), Erin Hoffman (Tradia), Steve

Hole (MessagingDirect Ltd.), Mary Holstege (Calico Commerce), Jim Hughes (Fujitsu Software

Corporation), Yin-Leng Husband (Hewlett-Packard, formerly of Compaq), Ryuji Inoue (Matsushita

Electric), Scott Isaacson (Novell), Murali Janakiraman (Rogue Wave), Eric Jenkins (Engenia

Software), Jay Kasi (Commerce One), Jeffrey Kay (Engenia Software), Richard Koo (VitriaTechnology Inc.), Alan Kropp (Epicentric), Julian Kumar (Epicentric), Peter Lecuyer (Progress

Software), Tony Lee (Vitria Technology Inc.), Amy Lewis (TIBCO), Bob Lojek (Intalio), Henry

Lowe (OMG), Brad Lund (Intel), Matthew MacKenzie (XMLGlobal Technologies), Murray

Maloney (Commerce One), Richard Martin (Active Data Exchange), Highland Mary Mountain

(Intel), Alex Milowski (Lexica), Kevin Mitchell (XMLSolutions), Ed Mooney (Sun Microsystems),

Dean Moses (Epicentric), Don Mullen (Tibco), Rekha Nagarajan (Calico Commerce), Raj Nair

(Cisco), Mark Needleman (Data Research Associates), Art Nevarez (Novell), Henrik Nielsen(Microsoft Corporation), Kevin Perkins (Compaq), Jags Ramnaryan (BEA Systems), Vilhelm

Rosenqvist (NCR), Marwan Sabbouh (MITRE), Waqar Sadiq (Vitria Technology Inc.), Rich Salz

(Zolera), Krishna Sankar (Cisco), George Scott (Tradia), Shane Sesta (Active Data Exchange),

Lew Shannon (NCR), John-Paul Sicotte (MessagingDirect Ltd.), Simeon Simeonov

(Macromedia, formerly from Allaire), Aaron Skonnard (DevelopMentor), Nick Smilonich (Unisys),

Soumitro Tagore (Informix Software), James Tauber (Bowstreet), Lynne Thompson (Unisys),

Patrick Thompson (Rogue Wave), Jim Trezzo (Oracle), Asir Vedamuthu (WebMethods), Randy

Waldrop (WebMethods), Fred Waskiewicz (OMG), David Webber (XMLGlobal Technologies),


f 32 24.4.2012 11:47


32/32

Ray Whitmer (Netscape), Stuart Williams (Hewlett-Packard), Yan Xu (DataChannel), Amr Yassin

(Philips Research), Susan Yee (Active Data Exchange), Jin Yu (Martsoft).

The people who have contributed to discussions on [email protected] are also gratefully

acknowledged.


SOAP Version 1.2 Usage Scenarios

Documents

Transcript of SOAP Version 1.2 Usage Scenarios