1
1.1
1.1.1 D- US-001 - Travel Agent
1.1.1.1 Primary Description
A travel agent wants to offer to customers the ability to book complete packages that may consist of services offered by various providers. The available services may include: air travel, train travel, bus tickets, hotels, car rental, excursions and other services such as insurance.
The goal of the consumer is to get the best combination of services and prices suiting their needs. The travel agent tries to maximize customer satisfaction and sell packages. Service providers aim to sell as many products as possible. Credit card companies guarantee and perform payments for purchased products.
In this scenario, service providers offer Web Services to that could be used by the Travel agent to query their offerings and perform various tasks such as reservations. Credit card companies provide services to guarantee payments made by consumers. The client should be able to query, reserve and purchase any available service. The basic steps of the interaction are listed below
The client interact with the travel agent to request information about various services.
Prices and avilability matching the client requests are returned to the client. The client can then perform one of the following actions:
The client can refine their request for information, possibly selecting more services from the provider (Repeat step 2). OR
The client may reserve services based on the responce. OR
The client may quit the interaction with the travel agent.
When a customer makes a reservation, the travel agent then check the avilability of the requested services with each service provider.
Either
All services are avilable, in which case they are reserved. OR
For those services that are not avilable, the clinet is informed.
Either
Given alternative options for those services. OR
Client is adiviced to restart the search by going back to step 1.
Go back to step 3.
For every relevant reserved service the travel agent takes a deposit for the reservation. A credit card can be used as a form of deposit
The client is then issued a reservation number to confirm the transaction.
Between the reservation time and the final date for confirmation, the client may modify the reservation. Modifications may include cancelleation of some services or the addition of extra services.
Client is expected to fully pay for those revelant services that require full payment prior to final confirmation.
The use case is illustrated in the figure below.
Figure X - ............
1.1.1.2 Requirements
Needs compensation to facilitate cancellation of orders and exception handling.
Needs callbacks to be able to express asynchronous interactions such as credit checking in a credit card company or availability from an airline.
Needs composition to be able to reuse established choreographies such as that used by a credit card company.
Needs reference passing to enable the car hire company to interact with the credit card company on behalf of the user.
Needs exception handling to be able to express observable actions to take on receipt of an exception message.
Needs timeouts to be able to express time to live on reservations.
Need hirareachle composition to facilitate the inclusion of the individual service type choreographies.
Need transactional boundaries to facilitate the integration of various tranactions
1.1.1.3 Variation on the use case
1.1.1.3.1 Variation 1
The travel agency might use a choreography definition internally as a documented model for its entire reservation booking process. The choreography definition language would need to present a multi-party global view of the reservation choreography, depicting the communication amongst the travel agent and all its various partners. Further, the definition language would need to support the addition of annotation or comments to the various elements of a choreography, in order to fully describe the behavior of the global choreography.
Requirements for variation 1
There MUST be a mechanism for adding annotation or comments to a choreography description.
A CDL must support the description of a multi-party global model.
1.1.1.3.2 Variation 2
The travel agent might assist new service providers to join its "network" by providing them with a choreography description outlining their communication responsibilities. The choreography definition language should support the construction of a global model (see above) and allow choreographies to reference one another, thus providing composition.
For instance, the travel agent would share a "credit check" choreography with a new credit bureau, and the travel agent's internal global choreography would simply include an instruction to "call credit check choreography". The global choreography could be composed of calls to many such nested choreographies. This has the added benefit of making the travel agent's global choreography modular and easier to understand.
Requirements for variation 2
A CDL must facailitate hierarchical decomposition to enable choreography descriptions to reference each other and to support some notion of abstraction to make descriptions easier to understand.
1.1.1.3.3 Variation 3
In order to protect against out-of-sequence messaging, a choreography participant might use a choreography definition to provide runtime validation of message typing and sequencing. When messages arrive they are checked for appropriate sequencing and, if the check fails, an exception is issued.
For instance, a rental car agency might wish to protect its backend systems from potential corruption by out-of-sequence messages -- for instance, a reservation being cancelled before it's ever placed. The corresponding action would be to respond to the offending document with an error message.
This runtime validation and exception generation are the responsibility of the choreography engine; however, the choreography definition language must not preclude the implementation of such a feature.
Requirements for variation 3
Failure to comply exception MAY be generated by a choreography
1.1.1.3.4 Variation 4
During the confirmation step, it may happen that one or more of the parties fails and are not immediately re-contactable. Depending on the urgency and importance of the travel services offered by the crashed parties, some form of recovery or correction may be required. In some cases it may be necessary to wait for the crashed parties to become active again, and to replay the messages back to them from some pre-defined checkpoint. The ability to demarcate such checkpoints is required in order to support this sort of scenario.
Requirements for variation 4
A CDL shall facilitate the demarcation of observable transactional behaviour.
When interacting with the various parties, a number of errors could occur. There will be system or infrastructure errors and failures that all choreographies would have to deal with, but more importantly there will be application/choreography specific errors that need to be considered and built into the choreography design. For example, between being offered services to a certain destination and confirming those services, it is entirely possible that the destination is withdrawn from sale for some travel advisory reason. When the client goes to book such services this should result in a set of error messages, that signify some erroneous state. Depending on how the actual web services are defined, these errors may simply be specific wsdl operations, or may be defined as wsdl faults; which is chosen is a web service design issue.
Additional requirements
A CDL shall support the description of application exceptions.
A CDL shall support the description of WSDl faults.
1.1.1.3.5 Variation 5
In this variation of the Travel Agent use case most of the main carriers (airlines) have in place a robust messaging infrastructure that delivers high qquality robust connections that ensure guaranteed delivery. However the rise of budget airlines means that a new class of carriers have become part of the overal offering from travel agents where the messing infrastructure is no where near as reliable.
Fortunately the same choreography description can be used for both classes of carrier and the only thing that needs to change on both sides of the connection is for the participants to bind to the underlying messaging protocol available.
Also in this variation each carrier has different correlation keys that are used to match messages that belong to a specific transaction. The choreography that is used across the various carrier types is left unchanged with only the binding to correlation different across them. For each instance of a choreography the choreography description, on instantiation with a participant, bind the appropriate correlation mechanism in to the choreography so that it may be followed. Binding on a per participant basis enables the choreography to use whatever correlation mechanism is required between any two participants.
Requirements for variation 5
There should be a binding mechanism to enable a choreography to bind to differing QoS as applied to messaging and to differing correlation mechanisms.