Design Framework for Domain-Specific Service
Interfaces
George Feuerlicht, Sooksathit Meesathit
Department of Software Engineering, Faculty of Information Technology,
University of Technology, Sydney,
PO Box 123 Broadway Sydney NSW 2007 Australia
Abstract. Following the rapid evolution of Web services standards and
technologies over the last three years many organizations are now beginning to
make significant investments in the implementation of Web services
applications. However, so far only limited attention has been paid to design
issues for service-oriented applications. This paper describes a design
framework for domain-specific service interfaces. The design framework
provides guidance for transformation of a document-oriented message
specification into a definition of service interfaces that can be used to generate
Web services. We illustrate the design framework using an example based on
the Open Travel Alliance (OTA) specification.
1 Introduction
While some of the features required for the implementation of secure and reliable
e-business applications using Web services are still under development many
organizations are making significant commitments to Web services standards and
technology platforms. As with other technology platforms, the success of large-scale
development projects using Web services will to a large extent depend on effective
design and development methodologies used in the construction of application
systems. As Web services constitute basic building blocks of service-oriented
applications, decisions about what constitutes a service, which operations should the
service support, and what service interfaces should be exposed are of vital importance
and will determine the quality and reliability of Web services applications.
Specification of stable, well-designed Web service interfaces is a key requirement for
ensuring high level of interoperability in complex e-business applications. Web
services implementation projects conducted in the absence of a design framework are
likely to suffer from poor reuse and extensibility as poorly designed interfaces lead to
duplication of functionally and poor maintainability of applications. Web services
design is an active area of research, but at present there are no comprehensive design
frameworks that can be used to assist designers with large-scale Web services
projects. Most existing approaches describe Web services design in the context of
enterprise application development and rely on object-oriented methods or
component-based techniques. For example, Papazoglou and Yang [1] focus on Web
services composition based on business process analysis, transforming business
Feuerlicht G. and Meesathit S. (2004).
Design Framework for Domain-Specific Service Interfaces.
In Proceedings of the 2nd International Workshop on Web Services: Modeling, Architecture and Infrastructure, pages 109-115
DOI: 10.5220/0002686001090115
Copyright
c
SciTePress
process definitions to Web services interface definitions. The design methodology is
based on the concepts of coupling and cohesion and the resulting set of Web services
is described using a Web services flow language (e.g. WSFL). Levi and Arsajani [2]
use a component-based approach, first decomposing a business domain into main
business processes, describing these business processes in the form of use cases, and
then using this information to design software components. Other approaches include
methods based on Model-Driven Architecture (MDA) [3], and Design by Contract
methodology [4]. Hammond [5] proposes the use of UML activity diagrams to model
business processes and information flows, translating UML models into WSDL
descriptions. Alternatively, existing specifications of business processes defined using
e-business standard such as RosettaNet can be used as a starting point for Web
services design. Masud [6] demonstrates how RosettaNet PIP (Partner Interface
Process) specifications can be translated into WSDL and BPEL4WS definitions. Web
services are modeled from RosettaNet PIP specifications mapping actions and their
corresponding document schemas to Web service operations.
1.1 Design of Service Interfaces for e-Business Applications
In the context of e-business applications the use of Web services represents a shift
from a document-centric to a service-oriented model for e-business communication
[7]. This will have a major impact on the design and implementation methods used for
development of e-business applications, making most existing methods unsuitable.
Rather then considering the design of individual enterprise applications we focus on
the problem of defining industry domain-specific service interfaces. This is an
important distinction as the key benefits of service orientation can be only achieved if
a consistent set of Web service interfaces is defined and used across an entire industry
domain (e.g. travel). This ensures that service providers (e.g. airlines, hotels, etc)
publish the same service interfaces, avoiding the need to interpret the semantics of the
interface for individual cases. The task of designing domain-specific service
interfaces is conceptually similar to designing a programming API (Application
Programming Interface); such APIs are used extensively in programming
environments (e.g. J2EE). More recently, APIs are being defined to facilitate
interoperability for learning technology platforms under the auspices of the Open
Knowledge Initiative consortium [8]. This MIT led initiative aims to provide
specification for educational services in the form of Java APIs to enable the sharing
educational objects across universities. The benefits of standardized service interfaces
include reusability, extensibility, and maintainability and lead to significant
application development productivity gains. In this paper we describe a design
framework for Web service interfaces that uses a industry domain standard
specification as a starting point and produces interface definitions for Web services
(section 2). The approach is illustrated using a travel application example based on
the OTA (Open Travel Alliance) specification [9]. In conclusion (section 3) we
discuss the benefits of standardization of domain-specific Web service interfaces.
110
2 Domain-specific Service Interface Design
Existing e-business domain standards are a good starting point for developing
domain-specific service interfaces as they capture extensive domain expertise and
contain comprehensive business models for a given industry sector. Industry domain
standards have been defined in most industry sectors, using EDI (Electronic Data
Interchange) format, ebXML, RosettaNet, or various industry-wide specifications
such OTA (Open Travel Alliance), and HL7 [10]. Existing industry domain standards
are mostly document-centric, i.e. they use document exchange as an interoperability
mechanism. This limits the interoperability and scalability of e-business applications
as the number of business partners increases and the complexity of the specification
grows. Web services remove the need to use document exchange as the
interoperability mechanism by providing a homogeneous application deployment
environment irrespective of the underlying technology platforms used by individual
partner enterprise applications. The key benefit of this approach is that e-business
applications can be programmed, in effect creating virtual applications operating
transparently across multiple partner computing environments. The success of this
approach is critically dependent on designing a set of standard service interfaces for a
given industry domain that can then be used consistently across all applications.
2.1 Travel Application Example
We illustrate our design approach using an example Travel Application based on
the OpenTravel Alliance consortium specification. OTA defines message payloads
using XML Schema for various aspects of the travel business, including air travel,
hotel accommodation, and car rentals. Comprehensive message formats specify the
information required for various business transactions. For example,
OTA_AirAvailRQ message format is a schema specification for a request for flight
availability information given a pair of cities on a specific date for specific number
and type of passengers. OTA_AirAvailRQ message contains a large number of
schema elements including passenger travel preferences (e.g. diet, seating
preferences, etc.). OTA specification is based on the request/response paradigm, and a
corresponding response message (OTA_AirAvailRS) that contains information about
flights matching the request criteria is defined. The design of the messages is
optimized with respect to performance over slow networks, maximizing the amount
of information transmitted within a single message payload. Each message contains
complex data structures and inherently represents a complex business process that the
receiving partly needs to map to their enterprise applications. Using Web services to
transmit messages with such complex data structures, while possible (i.e. using the
document style binding), would not take advantage of the benefits of service-oriented
computing, and result in limited scalability characteristic of document-centric e-
business applications.
Our approach is to de-compose complex business processes into elementary
business functions (i.e. business functions that cannot be further decomposed) and
identify the corresponding information requirements. We note that although, this is a
111
bottom-up composition approach, we rely on previously performed top-down analysis
of information requirements and business processes implicit in the OTA message
structures and accompanying description of business processes.
2.2 Identifying Operations
Given the OTA message format specifications, the task is to convert it into a set of
well-defined (domain standard) service interfaces that can be used to accomplish a
given business process, for example airline travel booking. The first step in this
process is identification of operations; this is then followed by specification of input
and output parameters for each operation.
Figure 2. Air travel booking process represented as a Sequence diagram
Airline travel booking typically consists of several discrete operations that can be
modeled using a Sequence Diagram as illustrated in Figure 2. We make a number of
simplifying assumptions in our Travel Application example, including that the travel
agent interacts with only two airlines (KLM and Qantas), and that the flight is
between a single pair of departure and destination cities. We assume that the business
process operates in the following way:
The travel agent sends a travel availability request messages to both airlines
specifying the departure and destination city, the date of travel, and other relevant
information. When the responses from both airlines are received, the travel agent
selects a particular flight based on some criteria (e.g. price), and possibly, after
consulting the traveler, and makes a booking with the selected airline. Finally, the
travel agent makes a request for itinerary information; optionally this could be
followed by additional requests (e.g. request to add royalty points). We summarize the
steps in the Travel Booking business process below showing the corresponding OTA
message request/response messages in the parentheses.
A
irItinerar
y
RS
A
irItinerar
y
RQ
SelectFlight
A
irAvailRS
AirAvailRQ
A
irAvailRQ
Travel.com:travel agent
KLM:airline
Qantas:airline
A
irAvailRS
A
irBookRS
AirBookRQ
112
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
Operations Type Input Output
AirAvail Query
(RPC)
OriginalLocation
DestinationLocation
DepartureDate
CabinPref {Optional}
Airline {Optional}
FlightNumber {Optional}
DepartureTime
ArrivalDate
ArrivalTime
Airline
FlightNumber
AirFare
AirBook Transaction
(RPC)
Airline
FlightNumber
DepartureDate
DepartureAirport
ArrivalAirport
TravelerName
BookingReferenceID
AirItinerary Document BookingReferenceID TravelerName
Airline
FlightNumber
DepartureAirport
DepartureDate
DepartureTime
ArrivalAirport
ArrivalDate
ArrivalTime
ActionCode
BaseFare
Taxes
AirCancel Transaction
(RPC)
BookingReferenceID CancellationID
CancellationFee
{Optional}
Table 1. List of operations and corresponding parameters for Airline Booking Service
As described in our earlier publication [7], given the specification of interfaces the
corresponding WSDL definitions for the Airline Booking Service can be generated,
and the Web service implemented and deployed.
3. Conclusion
In this paper we have presented a simple design framework for domain-specific
service interfaces and we have illustrated this approach using a travel example. The
approach uses industry domain document-centric message specification as a starting
point and produces a set of service interfaces that can be implemented using Web
services. Using this design framework we map message specifications to a sequence
diagram and then transform the sequence diagram into service interface definitions,
minimizing the exposure of metadata. The interface encapsulates details of the service
implementation, so that for example the AirCancel operation is implemented as an
RPC call with a single input parameter (BookingReferenceID).
114
Using standard service interfaces across an industry domain such as travel or
education results in an environment where e-business applications can be
implemented as a series of calls to remote services, with significant application
development productivity gains, and greatly improved application maintainability.
Service providers can expose additional (non-standard) service interfaces to provide
specialized business functions, if required. Another benefit of this approach is that
evolution can be supported via interface versioning, so that existing interfaces can be
maintained to support legacy applications. This avoids many of the problems
associated with evolution of document-centric, message-based standards (e.g. EDI).
In conclusion, service-oriented computing based on Web services standards and
technologies provides an opportunity to finally address many of the issues that inhibit
interoperability and automation of e-business applications. Industry standard service
interfaces are a key component of the service-oriented approach to e-business
applications. This paper illustrates how such interfaces can be developed from
document-centric message structures using a simple design framework.
References
1. Papazoglou, M.P. and J. Yang: Design Methodology for Web Services and Business
Processes. In Proceedings of the 3rd VLDB-TES Workshop. Hong Kong. Springer (2002)
2. Levi, K. and A. Arsanjani: A goal-driven approach to enterprise component identification
and specification. Communications of the ACM. Vol. 45:(10). (2002) 45 - 52
3. Frankel, D. and J. Parodi: Using Model-Driven Architecture™ to Develop Web Services.
IONA. (2002) http://portals.devx.com/assets/iona/2974.pdf
4. Meyer, B.: Object-oriented software construction. 2nd edn. Prentice Hall, Upper Saddle
River, N.J. (1997)
5. Hammond, J.: Introducing Web services into the software development lifecycle. Rational
software Corporation. (2002) http://www.rational.com/media/whitepapers/TP033.pdf
6. Masud, S.: Use RosettaNet-based Web services, Part 1: BPEL4WS and RosettaNet.
DifferentThinking. (2003)
http://www106.ibm.com/developerworks/webservices/library/ws-rose1/
7. Feuerlicht, J. Implementing Service Interfaces for e-Business Applications, The Second
Workshop on e-Business (WeB 2003), December 13-14, 2003, Seattle, USA.
8. Thorne, S. et al, OKI Architecture Overview, http://web.mit.edu/oki/learn/papers.html
(March, 2002)
9. OTA 2002, Available from: http://wwww.opentravel.org/2002a.cfm
10. HL7 Message Development Framework Version 3.3, December 1999, http://www.hl7.org/
11. Designing Web Services with the J2EE 1.4 Platform - Early Access. (2003)
http://java.sun.com/blueprints/guidelines/designing_webservices/
115