Web service use case: Travel reservation

Use case 5 May 2002

This version:
http://www.w3.org/2002/06/ws-example (XML version and HTML version)
Previous version:
http://www.w3.org/2002/04/17-ws-usecase
Editor:
Hugo Haas, W3C <hugo@w3.org>

Abstract

This documents attempts to put together a use case involving a set of Web services to serve as an useful example for Web services and to generate requirements for the Web Services Architecture Working Group.

This example, due to its very broad scope, will be incomplete, and will evolve over time. In its current state, this usage scenario is somewhat simplified: there might be additional security, privacy constraints, etc.

I attempted to use the method that one of the subgroups tried out at the April 2002 face-to-face meeting.

Status of this Document

This document is an editors' copy that has no official standing.

This document was incorporated in the 30 July 2002 version of the Web Services Architecture Usage Scenarios.

Please send comments on this documents on the www-ws-arch publicly archived mailing list.

Table of Contents

1 Description
2 Scope
3 Stakeholders / Interests
4 Actors & Goals
5 Usage scenarios
    5.1 1. User requests availabilities about some travel dates
        5.1.1 Goal / Context
        5.1.2 Scenario / Steps
        5.1.3 Extensions
        5.1.4 Technologies / Requirements
    5.2 2. User requests chooses flight and looks for hotels
        5.2.1 Goal / Context
        5.2.2 Scenario / Steps
        5.2.3 Extensions
        5.2.4 Technologies / Requirements
    5.3 3. User books hotel room and flight
        5.3.1 Goal / Context
        5.3.2 Scenario / Steps
        5.3.3 Extensions
        5.3.4 Technologies / Requirements
    5.4 Notes on the scenario

Appendix

A Acknowledgments


1 Description

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.

2 Scope

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.

3 Stakeholders / Interests

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

Service providers: sell their services by making them available widely.

Credit card company: enable customers to use their credit cards in a very large number of cases; make profit with each money transaction.

Consumer: book 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.

4 Actors & Goals

Consumer: best combination of services and prices for his/her needs.

Travel agent: customer satisfaction, sell packages.

Service providers: sell services.

Credit company: qualify buyer, do the payment.

5 Usage scenarios

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

Here is a list of diagrams giving an overview of the scenario, with the introduction of a new hotel service:

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:

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

5.1 1. User requests availabilities about some travel dates

5.1.1 Goal / Context

The user gets the location of a travel agent service via an unspecified way (search engine, URI in an email, service directory, etc).

The user provides a destination and some dates to the travel agent service. The travel agent service inquires airlines about deals and presents them to the user.

5.1.2 Scenario / Steps

  1. The user is presented with a form to fill in order to provide the travel agent service with details about dates of his/her travel and the destination.

  2. The user submits the information to the service in order to get a list of flights corresponding to his/her schedule.

  3. The travel agent service finds a list of airlines.

  4. For each airline found:

    1. The travel agent service requests a description of how to communicate with the service found.

    2. The travel agent service requests a list of flights accommodating the user.



  5. The travel agent service presents the results of the queries to the user letting him choose the best option.

5.1.3 Extensions

If no flight can be found, the user should be presented with an error.

5.1.4 Technologies / Requirements

Discovery technology: used by the travel agent service to find the airlines services.

Description language: used by the airlines to describe their query services to the travel agent service.

Response to queries: XML documents that the travel agent service processes and merge together.

Ontologies: the data coming from different airline services and expressed with different XML vocabularies needs some semantics to be merged in a meaningful way.

5.2 2. User requests chooses flight and looks for hotels

5.2.1 Goal / Context

The user has been presented with options for flights to go to his/her destination. The user chooses a preferred flight. The service puts the seats on hold, and goes on with proposing lodging options to the user.

5.2.2 Scenario / Steps

  1. The user communicates his/her choice for the flight.

  2. The travel agent service requests the chosen airline to put the flight on hold:

    1. The travel agent service requests a description of how to put a seat on hold to the airline service.

    2. The travel agent service sends the request accordingly.



  3. The airline returns a confirmation number with an expiry date.

  4. The travel agent service finds a list of airlines.

  5. For each hotel found:

    1. The travel agent service requests a description of how to communicate with the service found.

    2. The travel agent service requests accommodation options for the period.



  6. The travel agent service looks for payment services available, and builds a list of options for the user.

  7. The travel agent service presents the results of the queries to the user letting him choose the best option, along with the payment options offered.

5.2.3 Extensions

If the seats chosen are not available anymore, the travel agent service presents the user with an error message and the user is presented with an updated list of available flights to choose from.

5.2.4 Technologies / Requirements

Description language: used by the airlines to describe their services to put tickets on hold to the travel agent service, by the hotels to describe their query services to the travel agent service.

Discovery technology: used by the travel agent service to find the hotels services.

Ontologies: the data coming from different accommodation services and expressed with different XML vocabularies needs some semantics to be merged in a meaningful way.

5.3 3. User books hotel room and flight

5.3.1 Goal / Context

The user has been presented with options for hotels to go to his/her destination and a means of payment. The user chooses a hotel option. The travel agent service contacts a bank for payment authorization. The service books the hotel and confirms the flight, using the payment authorization from the bank.

5.3.2 Scenario / Steps

  1. The user communicates his/her accommodation choice to the travel agent service.

  2. The travel agent service contacts the bank service that the user chose to confirm payment:

    1. The travel agent service requests a description of how to guarantee payment of the total amount.

    2. The travel agent service send the request accordingly.

    3. The response indicates success with an authorization number, signed by the payment authority.



  3. The travel agent service books the hotel room:

    1. The travel agent service requests a description of how to book a room to the chosen hotel service.

    2. The travel agent service sends a request in order to find out how to cancel the reservation should a problem occur later in the process.

    3. The travel agent service sends the request accordingly, communicating the payment service chosen and the signed authorization number from this service.



  4. The travel agent service confirms the flight reservation:

    1. The travel agent service requests a description of how to buy a ticket on hold to the airline service.

    2. The travel agent service sends a request in order to find out how to cancel the reservation should a problem occur later in the process.

    3. The travel agent service sends the request accordingly, communicating the payment service chosen and the signed authorization number from this service.



  5. The travel agent service charges a fee to the user:

    1. The travel agent service requests a description of how to request payment to the payment service.

    2. The travel agent service sends the request accordingly, along with the authorization number signed by the payment service.



  6. The service provides the user with various confirmation numbers and wishes the user a good vacation.

5.3.3 Extensions

If the payment service doesn't confirm the validity of the user's payment option, the user should be presented with an error.

If the hotel room cannot be booked, the user should be presented with an error and should get to choose from an updated list of options.

If the flight reservation cannot be confirmed, the hotel room reservation should be canceled and the user should be presented with an error and start the reservation process again.

5.3.4 Technologies / Requirements

Service description technology: used by the payment authority to describe its confirmation service, by the hotel to describe its room booking service, and by the airline to describe its service to buy tickets by confirming seats on hold.

Authentication technology: used by the payment authority to sign the payment authorization to be trusted by the hotel service, the airline service and the travel agent service.

Encryption technology: used by the payment service and the travel agent service to communicate the user's payment information confidentially.

Ontologies: the payment confirmation needs to be used in a way meaningful to the travel service, hotel and airline services; in other words, the output of one service needs to be used as the input to other services that might use different vocabularies.

5.4 Notes on the scenario

This scenario illustrates how a program, the travel agent service, can interact dynamically with airline services, hotel services, without a priori knowledge of them or of the way they work. Thanks to the ontologies used, the program can adapt to variations of formats that an airline service might be using and adapt to the introduction of new products.

However, there is a limit to what the travel agent service can understand. For example, it is likely to be able to understand the introduction of a new class of tickets, say class Z. However, if the restrictions on class Z tickets use concepts that it is not aware of (say that class Z tickets can only be bought more than 60 days in advance and with a valid international student identification), the developers of the travel agent service will need to implement the extra logic to make it understand this new type of restriction, including validating the student identification.

A Acknowledgments

Thanks to Eric Prud'hommeaux and David Booth for their comments, and to Max Froumentin for his help converting the document to XML (see stylesheet applied on the XHTML version).