A sender wishes to send an unacknowledged message to a single receiver (e.g. send a stock price update every 15 minutes).

A sender wishes to send unacknowledged messages to a set of receivers (e.g. send a stock price update every 15 minutes).

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's responses may include order confirmations, change control information and contractual acknowledgements.

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 is returned 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.

The sender invokes the service by passing parameters that are serialized into a message for transmission to the receiving server.

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.

Declaration of a method that raises multiple faults

A web service interface method can fail due to several reasons. The faults raised by the method may be semantically different from each other and further more, some of the faults may be standard faults defined for a group of web services. For example, in an accounting system, there may be a general "creation fault" defined for indicating the failure such as out of resources or PO already exists. The creation of PO could also fail because the data provided to initialize the PO is invalid. The web service method "createPO" might then fail because of any of the reasons described above and may want to raise separate faults depending on the reason for failure.

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:

A blind auction marketplace serves as a broker between buyers and suppliers. Buyers submit 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.

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 header information. 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.

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 cacheability 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, or implied 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, the presence of a particular element may be a trigger for a cacheability mechanism to be applied to another element, such as validation or invalidation.

Caching is frequently used as an optimization in distributed systems. It can be used to avoid 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.

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 service without 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.

This scenario has been addressed in detail by the WS-Routing (formerly SOAP-RP) specification.

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.

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.

See description for DS24.

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.

A sender wishes to exchange data with a receiver and has agreed to encrypt the all of or a portion of 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. This scenario is applicable to the Travel Reservation Use Case (see ).

Two trading partners engaged in a message exchange may agree to cryptographically sign and verify one or more message header, such as a routing header or a conversation header, 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. This scenario is applicable to the Travel Reservation Use Case (see ) for the communications to the credit card service, where the message is not being sent over a secure channel, such as SMTP.

Two trading partners engaged in a message exchange may agree to cryptographically sign and verify an attachment, that is content that is not directly part of the SOAP envelope. The sender or originating application may perform the encryption of the attachment. This scenario is applicable for the Travel Reservation Use Case (see ) for the communications to the credit card service, where a image of a signature is attached to the message.

In scenario S061, two applications communicated using encrypted payloads. These opaque payloads had no impact on the SOAP processing layer. In this scenario, the action of encrypting the attachment is the responsibility of the SOAP processing layer. This scenario is similar to S062.

A web service client presents credentials or tokens to a web service.

WS-Arch WG Specific Requirements

Shall support Username/password credential

A sender and receiver may wish to be able to determine if a message has been modified in transit, and point-to-point encryption is not appropriate, perhaps because of intermediaries or system architecture choices.

WS-Arch WG Specific Requirements

Sign arbitrary portions of a document

Part of a request sent to a Web service need to be authenticated, e.g. to guarantee that a payment authorization for a purchase was issued by a well-known and trusted bank.

A request is sent from a user to a Web service. This request contains some payment authorization issued by a payment service.

Before processing the request, the service verifies that the payment authorization information has been issued by a valid payment organization (bank, credit card company, ...).

Variant of this scenario: the user sends the request to the Web service via the payment organization, with a payment authorization request. The payment organization processes the payment authorization request, includes payment authorization information with a signature guaranteeing its authenticity. It then forwards it to the Web service; the request contains at this point the original request from the user along with the signed payment authorization.

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 with the 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.

Capture the synchronicity of the operations

To negotiate proper communication sequence WS provider has to be able to describe if certain operations can be handled asynchronously, must be handled asynchronously or synchronously and what is the expected execution time. This would allow process orchestration system to properly adjust the flow and not run into unexpected blocking.

WS-Arch WG Specific Requirements

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 permitted due to device limitations or firewalls.

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, direct archiving 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.

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.

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.

Specifying streaming with input or output

A webcam is plugged in to a network. A user sends through the network an HTTP request to get the video. The webcam answers to this request by streaming the video to the user. The user sends another request to stop the streaming. I think WSDL should provide a way to express that it will use streaming at some point. Streaming might be used at two levels: - at the protocol level : the service may transmit the result by streaming - at the datatype level : the service may indicate that it will receive/send streaming as input/output..

Capture event management model for web services

WS-Arch WG Specific Requirements

A sender wishes to determine if a service is available. It sends a synchronous message querying the status of the service. Later, the sender sends an asynchronous message to the service. The sender then wishes to determine or control the status of the asynchronous message. It sends a synchronous message querying the status of the asynch message.

Service providers can provide custom data

A WS provider can decorate various elements of the service description with custom attributes. These attributes may be application specific and would be described by the WS provider in an additional documentation. Such custom attributes may be defined in a specific schema. WS provider may include such extra information as owner e-mail, link to SLA, security and session requirements for a particular message, etc.

A conversation between two trading partners may also be defined by shared configuration information such as an ebXML Collaboration Profile Agreement (CPA). A conversation agreement includes information such as expected response times, business process actions that each party undertakes to complete, security information and message content structures.

Declaration of service level attributes

Two web services, implementing the interface for "looking up for insurance providers", from different sources are offered in a registry. One of the two services actually performs extensive data validation on the data provided, for example making sure that the zip codes in the address provided are valid", while the other web service assumes that the data provided is valid and searches for insurance providers has already been validated and uses it to perform its search without any further validation. The interface was developed by an industry consortium that agreed to reflect the data validation capability of the services as a service-level attribute. Some intelligent registries may then actually allow search criteria that can be predicated on these service-level attributes or alternatively, the client application may check the value of the service level attribute itself at runtime to find out its value. The service-level attribute may be mapped to accessor methods which can be invoked either by the intelligent registry as part of executing the search query or by the client application itself.

In an advanced architecture where distributed transactions are supported, a web service may want to declare some of its operations as transactional as opposed to the entire interface being transactional. A web service offering various financial related web services may be able to verify a buyer's credit in a non-transactional manner but may require the client application to start a transaction before invoking the operation to prepare an invoice. The target web service may have a declarator on the method specification that indicates that the operation for invoicing requires transaction

. It has to be required that namespaces are not getting lost between service provider and the client. It should be part of WSDL compliance.

A WS provider can describe versions of interfaces implemented by a service. WS client can bind to the necessary interface version. This way there is no ambiguity when WS provider changes service interfaces and client has created a static proxy that uses previous version of interfaces. WS provider can deprecate and remove interfaces as desired, and the client would know that. Client would send a SOAP request that would not be accepted (as namespaces do not match), as opposed to client trying to send a SOAP request that could be accepted, but improperly executed.

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 initial SOAP 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.2 specifications. 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 marked mustUnderstand, 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, 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. The Binding Framework allows for additional properties, outside the SOAP envelope, that may be required 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 network device 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 binding must 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 the capability 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

Given a particular service address, a sender wishes to determine the description of the service

A Sender has the URL for a service. It sends a message to a the service requesting the WSD definition that is appropriate. This could be designed using standardized SOAP messages with particular parameters, or other designs

WS-Arch WG Specific Requirements

Service Providers can publish WSD of service(s)

Description

WS-Arch WG Specific Requirements