Web Services Architecture Usage Scenarios

A company (travel agent) wants to offer to people the ability to book complete vacation packages: plane/train/bus tickets, hotels, car rental, excursions, etc.

Service providers (airlines, bus companies, hotel chains, etc) are providing Web services to query their offerings and perform reservations.

Credit card companies are provide services to guarantee payments made by consumers.

This use case assumes that the discovery of the specific service providers and metadata happens prior to the invocation, and that a developer uses the description to create the web service invocation. This could be considered a "static" use case.

For this version of the usage scenario, we will limit ourselves to booking of vacation packages. We will assume that cancellation is not possible once a package has been purchased.

The travel agent provides a system to provide the user with options for his/her vacation and earns money by charging fees for each package bought.

Service providers (hotels, airlines) sell their services by making them available widely using Web services.

Credit card companies enable customers to use their credit cards in a very large number of cases by making payment Web services available and make profit with each money transaction.

The consumer books a vacation easily by choosing among a large variety of offers.

Only the user in the scenario is a human being. The travel agent service, airline, hotel and payment services that the travel agent service is interacting with, are machines.

The goal of the consumer is to get the best combination of services and prices suiting his/her needs.

The travel agent tries to customer satisfaction and sell packages.

The service providers are aiming at selling as many products as possible.

The credit card companies guarantee and do the payments of the purchased products.

Developers use WSDL and platforms to create instances of web services.

The following usage scenarios describe how a user would make a reservation for a vacation package (flight and hotel room), and how a developer would create a portion of a service.

It has to be noted that some additional technology is or may be needed for this usage scenario:

• context maintenance.

• reliability: in order to make money, each step needs to happen.

• trust mechanisms for the services to do business with each other.

• description of orchestration of services: if a reservation of a flight involves interacting with a couple of Web services, the airline would document in a machine readable way how to interact with the two single services in order to get the desired result, including how to handle errors in the process fails before the operation is completed.

• transactions: either compensating or atomic transactions may make the implementation of the reservation be of higher quality.

• ...

Note that this usage scenario could be different in the following ways:

• the user could have bought some travel agent software; the travel agent service could reside locally on his/her computer.

• the user could write tools to interact directly with the airline and hotel services.

A company (travel agent) wants to offer to people the ability to book complete vacation packages: plane/train/bus tickets, hotels, car rental, excursions, etc.

Service providers (airlines, bus companies, hotel chains, etc) are providing Web services to query their offerings and perform reservations.

Credit card companies are also providing services to guarantee payments made by consumers.

Due to the loosely coupled-nature of Web services, the travel agent doesn't need to have a priori agreements with service providers or credit card companies. This allows the travel agent to have access to more services, offering more options to its customers, the credit card companies to offer their services broadly and therefore make their customers happy, and the service providers can offer their services broadly and easily and therefore generating more business for themselves.

For this version of the usage scenario, we will limit ourselves to booking of vacation packages. We will assume that cancellation is not possible once a package has been purchased.

The travel agent provides a system to provide the user with options for his/her vacation and earns money by charging fees for each package bought.

Service providers (hotels, airlines) sell their services by making them available widely using Web services.

Credit card companies enable customers to use their credit cards in a very large number of cases by making payment Web services available and make profit with each money transaction.

The consumer books a vacation easily by choosing among a large variety of offers.

Only the user in the scenario is a human being. The travel agent service, airline, hotel and payment services that the travel agent service is interacting with, are machines.

The goal of the consumer is to get the best combination of services and prices suiting his/her needs.

The travel agent tries to customer satisfaction and sell packages.

The service providers are aiming at selling as many products as possible.

The credit card companies guarantee and do the payments of the purchased products.

The following usage scenarios describe how a user would make a reservation for a vacation package (flight and hotel room).

An assumption for this usage scenario is that all the services are using common concepts (e.g. flight, economy class, room, etc). For the travel agent service to understand the airline services and to be able to send meaningful information to them, a travel industry ontology needs to exist and be used by the Web services taking part in this scenario. An ontology is a formal description of a set of concepts and their relationships to each other. By associating a name with each concept, an ontology defines a standard vocabulary that can be used to communicate those concepts.

It has to be noted that some additional technology is needed for this usage scenario:

• context maintenance.

• reliability: in order to make money, each step needs to happen.

• trust mechanisms for the services to do business with each other.

• description of orchestration of services: if a reservation of a flight involves interacting with a couple of Web services, the airline would document in a machine readable way how to interact with the two single services in order to get the desired result, including how to handle errors in the process fails before the operation is completed.

• ...

Note that this usage scenario could be different in the following ways:

• the user could have bought some travel agent software; the travel agent service could reside locally on his/her computer.

• the user could write tools to interact directly with the airline and hotel services.

The focus of this use case is the technical infrastructure required to implement the business processes, not the business processes themselves. In this example we will assume that BigCo and SmallCo have already set up their trading relationship. How they found each other and made the agreement to trade with each other is beyond the scope of this example. Payments in this example are sent through financial institutions and involve electronic processes beyond the scope of this example (because it is beyond the scope of the EDI people whose experience forms the basis of this use case). Opinions may differ about what aspects of the requirements belong in Web Services "technical infrastructure" and which belong in "business process". For example, we think that unique ID and timedate stamping of the messages should be "infrastructure" but that sequencing of the messages belongs in "business process". These issues are discussed as they arise below.

BigCo purchases widgets, both via EDI provided by a VAN and via web services as described in this use case. BigCo uses big software packages internally. For example, financials and business information are handled by an ERP system, and there is an eProcurement front end (perhaps from a different provider) that implements the purchasing logic. Connectivity and data transport within the company are provided by an EAI system. BigCo's primary motivations in this activity are cost control, reliability and security. Automated processing is much cheaper than typing invoices in by hand and also can be more accurate.

SmallCo manufactures widgets and gets orders from BigCo occasionally (perhaps a few per month). SmallCo's primary motivation is to do business with BigCo and other companies of this sort, and messing with electronic procurement systems is part of what you need to do to get the sale. However, SmallCo needs to keep the cost down and cannot afford to purchase elaborate software systems to implement these processes. SmallCo uses a low-end bookkeeping system (e.g. QuickBooks, PeachTree Accounting) and does a lot of hand entry into this system. SmallCo has a web site hosted by a local ISP.

BigCo: A business analyst is responsible for the relationship between BigCo and SmallCo, an engineer initiates the request for purchase, the purchasing department handles the mechanics of the transaction.

SmallCo: Mom takes the order and tells Sonny to ship out N widgets, meanwhile telling Pop to enter the transaction into Quickbooks and generate an invoice against BigCo.

The following usage scenarios first illustrate the steps involved in a typical purchasing transaction, then show some typical "fixing the screwups" operations.

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.

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

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.

An application requests some information from a server, which is returned at a later time in multiple responses. This can be because the requested information was not available all at once (e.g., distributed web searches).

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:

1. The data has been successfully delivered to the receiver, or

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

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

<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope">
  <env:Header>
    <n:StatusRequest xmlns:n="http://example.org/status">
      <n:MessageId>uuid:09233523-345b-4351-b623-5dsf35sgs5d6</n:MessageId>
    </n:StatusRequest>
  </env:Header>
  <env:Body>
    -----
  </env:Body>
</env:Envelope>

<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope">
  <env:Header>
    <n:StatusResponse xmlns:n="http://example.org/status">
      <n:MessageId>uuid:09233523-567b-2891-b623-9dke28yod7m9</n:MessageId>
      <n:MessageStatus>DELIVERED</n:MessageStatus>
      <n:Timestamp>2001-03-09T12:22:30Z</n:Timestamp>
    </n:StatusResponse>
  </env:Header>
  <env:Body>        
    -----
  </env:Body>
</env:Envelope>

1. A Sender shall be able to determine from a receiver message whether a message has been reliably delivered, as specified by the receiver.

2. A sender and receiver shall be able to engage in message exchange patterns that exhibit best-effort, at least once, at most once, ordered qualities of service.

1. specifying quality of service of the sender/receiver software, particularly the durability of the message on a particular side. Justification: QoS would be a static definition, not part of a reliability ACK Protocol. It seems in appropriate to specify a software quality in a wire-protocol.

2. Sender over-riding receiver default QoS (i.e. TCP's ack before enqueue)

OASIS WS-Reliability, WS-RM, WS-Acknowledgement, ebXML Messaging Service, Proprietary Messaging Systems, Java Messaging Service

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.

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.

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.

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.

Interactions between business partners are usually more complex than a single request/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. In a procurement process, an example conversation may be:

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

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

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

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

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

All of the example message exchanges are related an instance of any agreement between the two partners. For a message to be valid as part of the agreed rules, each partner has to check whether the current message is valid within the scope of the TPA.

Figure 10 illustrates how this scenario could be implemented. Each partner's SOAP processor has access to a database which is configured by the agreement 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 sender's information to test whether the received message is acceptable within the rules of the agreement. 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 message violates the rules of the agreement, then the application can raise a fault condition.

Note that Figure 10 does not include handlers for other message headers to support reliability or security which may be required under the agreement.

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.

<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope">
  <env:Header>
    <n:ConversationState xmlns:n="http://example.org/conversation">
      <n:AgreementId>uuid:09233523-345b-4351-b623-5dsf35sgs5d6</n:AgreementId>
      <n:ConversationId>uuid:02957815-38fh-39gp-0dj2-dm20fusy1n5j</n:ConversationId>
    </n:ConversationState>
  </env:Header>
  <env:Body>
    -----
  </env:Body>
</env:Envelope>

<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope">
  <env:Header>
    <n:ConversationState xmlns:n="http://example.org/conversation">
      <n:AgreementId>uuid:09233523-345b-4351-b623-5dsf35sgs5d6</n:AgreementId>
      <n:ConversationId>uuid:02957815-38fh-39gp-0dj2-dm20fusy1n5j</n:ConversationId>
    </n:ConversationState>
  </env:Header>
  <env:Body>
    -----
  </env:Body>
</env:Envelope>

1. A Sender shall be able to specify information in a message for its internal use. The sender shall send the same information for subsequent messages in a given conversation. The receiver is required to echo this information for messages in a given conversation. An example of this is a client-side conversation ID.

2. A Receiver shall be able to specify information in a message for its internal use. The receiver shall send the same information for subsequent messages in a given conversation. The sender is required to echo this information for messages in a given conversation. An example of this is a server-side conversation ID.

3. A Sender and a Receiver shall have a specification of sequences of allowable messages. This is sometimes called choreography, orchestration, or workflow. An example of this is Robin Milner's pi calculus.

4. A Sender and a receiver shall have a specification of the static characteristics of the interchange. The agreement might be specified in some or all of the messages exchanged.

1. starting/stopping conversations at the protocol level. This is an application feature.

2. timing out conversations at the protocol level. This is an application feature.

Sequencing aka choreography: WSCL, WSFL, XLang

Conversations: ebXML Message Service

Static characteristics: ebXML CPP/CPA, WSEL?

Scenario S061 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.

<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope">
  <env:Body>
    <m:PurchaseTicket xmln:m="some-URI">
      <m:PNR>ABCDEFGH</m:PNR>
      <m:CreditCard>4500123456789abc</m:CreditCard>
    </m:PurchaseTicket>
  </env:Body>
</env:Envelope>

The following is the encrypted version of the above plain SOAP message. The body entry <m:PurchaseTicket> is encrypted using a symmetric key identified by the key name "Symmetric Key" and replaced by the <xenc:EncryptedData> element with an id "encrypted-body-entry". A <sec:Encryption> header entry for this encrypted data is added to the SOAP header. Note that the <sec:EncryptedDataList> element in the header entry has a reference to the <xenc:EncryptedData> element. The symmetric key used for encryption is stored in the <xenc:EncryptedKey> element in the header entry in an encrypted form, that is, it is encrypted by John Smith's RSA public key.

<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope">
  <env:Header>
    <sec:Encryption xmlns:sec="http://schemas.xmlsoap.org/soap/security/2000-12"
                       env:actor="some-URI"
                       env:mustUnderstand="true">
      <sec:EncryptedDataList>
        <sec:EncryptedDataReference URI="#encrypted-body-entry"/>
      </sec:EncryptedDataList>
      <xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
                            Id="EK"
                            CarriedKeyName="Symmetric Key"
                            Recipient="John Smith">
        <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
        <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
          <ds:KeyName>John Smith's RSA Key</ds:KeyName>
        </ds:KeyInfo>
        <xenc:CipherData>
          <xenc:CipherValue>ENCRYPTED 3DES KEY......</xenc:CipherValue>
        </xenc:CipherData>        
        <xenc:ReferenceList>
          <xenc:DataReference URI="#encrypted-body-entry"/>
        </xenc:ReferenceList>
      </xenc:EncryptedKey>
    </sec:Encryption>
  </env:Header>
  <env:Body>
    <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
                           Id="encrypted-body-entry"
                           Type="http://www.w3.org/2001/04/xmlenc#Element">
    <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:RetrievalMethod URI="#EK" Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"/>
        <ds:KeyName>Symmetric Key</ds:KeyName>
      </ds:KeyInfo>
      <xenc:CipherData>
        <xenc:CipherValue>ENCRYPTED BODY ENTRY......</xenc:CipherValue>
      </xenc:CipherData>        
    </xenc:EncryptedData>
  </env:Body>
</env:Envelope>

1. Encrypt portions of the payload

2. Point to Point

3. Specification of c14n algorithm used. Perhaps in spec, or in WSD?

1. Intermediaries. Justification: While intermediaries will be very important, a first version of security would be greatly successful without

SOAP-Security, WS-Security

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

1. Shall support Username/password credential

2. Shall support binary credentials, such as X.509 certificates

3. Shall support authentication across trust domains.

4. Shall define a trust model.

HTTP Authentication, WS-Security

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.

1. Sign arbitrary portions of a document

2. Shall use Digital Signatures

SOAP Security, WS-Security

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.

1. The security framework must support authentication of data.

2. It must be possible to sign part of messages.

XML-Signature, WS-Security

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.

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 as two 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 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.

<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope">
  <env:Header>
    <n:MsgHeader xmlns:n="http://example.org/requestresponse">
      <n:MessageId>uuid:09233523-345b-4351-b623-5dsf35sgs5d6</n:MessageId>
    </n:MsgHeader>
  </env:Header>
  <env:Body>
      ........
  </env:Body>
</env:Envelope>

<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope">
  <env:Header>
    <n:MsgHeader xmlns:n="http://example.org/requestresponse">
      <n:MessageId>uuid:09233523-567b-2891-b623-9dke28yod7m9</n:MessageId>
      <n:ResponseTo>uuid:09233523-345b-4351-b623-5dsf35sgs5d6</n:ResponseTo>
    </n:MsgHeader>
  </env:Header>
  <env:Body>
      ........
  </env:Body>
</env:Envelope>

1. . A sender shall be able to specify a URI for a receiver to send subsequent messages to, aka callback.

   1. This address can be contained in a message (dynamic)

   2. This address can be defined at an interface (static)

   3. This address can be specified in a 3rd party

Static: ebXML CPP/CPA

Dynamic: WS-Address, WS-Callback

Third Party: ebXML Registry, UDDI

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.

Transaction contexts are shared between to systems

WS-Transaction, WS-Coordination, OASIS BTP

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.

SOAP with Attachments, DIME, Infoset Addendum to SwA

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.

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.

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.). The notifications of such events could be delivered to a management application.

Capture event management model for web services

A sender or other party sends messages to a receiver inquiring about the status of the service or message or to control the execution of the message

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.

1. Shall be possible to "ping" availability of service

2. Shall be possible to query message status

3. Shall be possible to control message

ebXML Ping, Status messages

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.

1. Information inline in the WSDL

2. Information external to the WSDL

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.

Declaration of operational level attributes

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

To maintain namespaces through service providers and clients

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

Specifying interface versioning

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.

Imagine a component framework in which components and their operations (building finally the component's functionality) should be described with WSDL. In the framework the components are using operations from each other dynamically: in the program code there is no "hard-wired" function call but instead a "semantic description/reference" of what kind of operation to use, which will be dissolved just in time before execution. With this "semantic description" a search for suitable operations could be started in a (logical) centralized registry (maybe with UDDI). The registry contains (WSDL) information of all currently available components/operations within the framework. Result of the search query are the concrete binding parameters (protocol, URL, operation signature, etc.) of the matching operations. Finding a suitable match _automatically_ (without manual/human interaction) will be done by searching in the registered WSDL files for the specified "semantic description". One half of this "semantic description" are the parameters defined with complex XML schema types. The other one should be the determination of the operation (i.e. its functionality). But only considering the operation name has the same drawbacks as comparing parameters only by their name (or even simple types like integer, string, etc.): only operations with exactly the same name as chosen from the operation's programmer are returned. So with introducing a kind of "type system" for operations (or maybe a classification) would bring the benefit that the result set of the above mentioned query could return operations with different names, but which are implementing the same functionality/behavior. With this it would also be possible to exchange one component (respectively their operation/s) with another independently developed one, which has the same functionality but with (maybe only slightly) different operation name(s) - and this without further manual interaction.

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).

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

A Sender has an identifier 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

If the identifier is a URL, then the developers tools interact directly with the URL according to a TBD mechanism.

If the identifier is a QName, then how is the WSDL retrieved. Is there a potential issue?

1. A sender and receiver shall be able to exchange WSD descriptions given just a URI for the receivers service.

WS-Inspection,

People or Software use a registry to discover web services and the interface specifications.

1. Service Providers can publish WSD of service(s)

2. Service consumers can discover WSD of service(s)

3. Service consumers can invoke Services based upon discovered service description

UDDI, ebXML Registry