![](bg5.png)
1. Availability check (AirAvailRQ/AirAvailRS)
2. Flight booking request (AirBookRQ/AirBookRS)
3. Request for itinerary (AirItineraryRQ/AirItineraryRS)
4. Request for rules and conditions (AirRulesRQ/AirRulesRS)
5. Request to add royalty points (AirRoyaltyRQ/AirRoyaltyRS)
For completeness we also define a cancellation request
(AirCancelRQ/AirCancelRS) not specified by OTA. Individual messages in the
sequence correspond to elementary business functions. Elementary business functions
can be regarded as candidate Web services operations. Using this approach the
granularity of Web service operations is determined by the corresponding elementary
business functions. Larger granularity operations can be created by composition, i.e.
by implementing an interface that uses the basic operations to implement a more
complex business process. For example, the lowest airfare search operation
(LowestAirFareSearch) could be implemented using availability request operations
(AirAvailRQ) executed for various airlines, and by determining the minimum airfare.
We note here that we are not concerned with workflow aspects of the business
process, and purely use the Sequence Diagram as a modeling tool to facilitate the
design of service interfaces.
2.3 Defining Interfaces
Service interface definitions consist of specification of operations and assignment
of input and output parameters for each operation. Following the identification of
operations in section 2.2 above, the interfaces (input and output parameters) for each
operation are defined. As noted earlier (see discussion in section 2.1 above), the
original OTA messages contain complex data structures combining multiple business
functions into a single message, and include a large number of optional data items to
accommodate various customization requirements – this is characteristic of the
document-centric approach and leads to unnecessary dependencies that inhibit
evolution of the application. An important interface design goal is to minimize the
exposure of metadata in order to reduce inter-dependencies between applications. The
corresponding message structures need to be decomposed and relevant parameters for
individual operations identified. The interface should only contain parameters that are
required for a specific operation. For example, the original OTA AirAvialRQ message
contains many data items that are not directly required to check flight availability, and
the interface can be reduced to a relatively small number of input and output
parameters. It is useful to classify the operations according to the type of the request
performed. We classify operations into three types: query operations that execute a
query on a remote resource (e.g. availability check), transactions that perform a
transaction on a remote resource (e.g. booking request, or flight cancellation), and
document request (e.g. itinerary request). The type of operation determines the Web
services binding style; typically the binding style for query requests and transactions
is RPC (Remote Procedure Call), and for document requests is document. Other
approaches use different classifications, for example J2EE specification for Web
services design uses three categories: information Web services, transactions, and
business processes Web services [11]. Table 1 shows operations and the
corresponding interface definitions for the Airline Booking Service based on the
business process described in section 2.2 above.
113