Software Development Methodology for Web Services
Towards Software Development Methodology for Web Services
George FEUERLICHTa, Sooksathit MEESATHITb
Faculty of Information Technology,
University of Technology, Sydney,
PO Box 123 Broadway Sydney NSW 2007 Australia
a,
Abstract. The emergence of Web services represents a shift from component-based architectures that have proved successful in the context of enterprise computing to service-oriented architectures that are more suited to the highly distributed Internet-based applications. This trend towards service-oriented computing necessitates the re-evaluation of software development methodologies that are used in the construction of distributed applications. With growing acceptance of service-oriented computing and increasing number of large-scale Web Services projects there is some evidence that practitioners involved in implementing these solutions are paying only limited attention to how such applications should be designed. Frequently, the design of Web Services applications is driven by performance and scalability considerations, rather than any sound software engineering principles. A comprehensive methodological framework is required to guide designers and developers of service-oriented applications through the various phases of software development life cycle with specific emphasis on producing stable, reusable and extendable services.
In this paper we discuss design of service-oriented applications from a software engineering perspective, and propose a software development framework for Web Services based on identification of elementary business function using business function decomposition and mapping these functions to service operations. We apply interface design principles adapted from object-oriented design as guidelines for the design of services.
Keywords. Software development, Methodology for service-oriented applications, Web Services
Introduction
Web Services are being increasingly used as an application development and integration platform within enterprises and to implement e-business applications in various industry sectors. Examples range from relatively simple Web Services designed to provide programmatic access to popular websites such as Google ( Amazon ( eBay ( and Yahoo ( to comprehensive Web Services solutions provided by travel industry companies such as Galileo ( and Sabre ( While Web Services are becoming the preferred platform for implementing Internet applications and sophisticated Web Services development tools are becoming widely available, there is some evidence that practitioners involved in Web Services projects are paying only limited attention to how such applications should be designed. This can lead to project failures as the overall quality of service-oriented applications depends largely on the quality of their design that in terms determines reusability, extensibility and reliability of the applications.
Web Services design is an active research area and although there is some agreement about the basic design principles there are no comprehensive software development methodologies for Web Services at present. Many existing approaches focus on designing Web Services from components using object-oriented methods or component-based techniques. Web services development tools that support development and deployment of Web Services applications are widely available and simplify the coding and deployment phases of the software development life cycle using code generation techniques to produce WSDL and deployment files. However, software development tools can only assist developers by reducing the programming effort, and in general transform existing components by directly mapping component methods into Web Services operations, without providing much scope for making design decisions based on methodological support. Although there are similarities between software components and services, mapping existing components directly to Web Services can lead to suboptimal design and results in poor performance, reduced scalability, and complex interdependencies between services. It is evident that existing object-oriented and component-based design and development methodologies are not directly applicable to Web Services.
In this paper we discuss design of service-oriented applications from a software engineering perspective, and propose a software development methodology for Web Services. We first review existing literature on design of Web Services (section 1), and then describe a software development framework based on identification of elementary business function and mapping these functions to service operations (section 2). Using a travel example scenario based on the Open Travel Alliance specification (OTA, we illustrate how the methodology can be used to develop a consistent set of Web Services from an industry-domain specification of XML message structures. In conclusion (section 3) we compare our methodology to document-centric and message-oriented Web Services approaches, discussing relative advantages of the proposed methodology.
1. Related Work
In this section we review literature on the available methods for Web Services design, grouping these methods into approaches based on object-oriented and component design (section 1.1), methods for transformation of industry domain specifications (section 1.2), and business process transformation approaches (section 1.3).
1.1. Object-Oriented and Component-based Approaches
Ambler [1] proposed a methodology for deriving Web Services specifications from UML class diagram of existing object-oriented applications. The methodology identifies five types of classes: user interface classes, business/domain classes, process classes, persistence classes, and system classes. The first step in this methodology involves eliminating persistence classes and system classes from the class diagram. Persistence classes are classes that encapsulate access to persistent stores, while system classes are classes that encapsulate technical features; as these types of classes do not relate to business methods they do not need to be considered as candidates Web Services. Next step involves the simplification of hierarchies (both inheritance and aggregation hierarchies) of the remaining classes. Two simplification rules are defined: the rule for inheritance hierarchy involves the elimination of subclasses that do not add new contracts (i.e. public method), and the rule for aggregation hierarchy is to ignore classes that are not associated with other classes outside of the aggregation hierarchy. This step is followed by the identification of class contracts, i.e. public methods that can be called by objects in other classes, and removing all operations that are not class contracts (i.e. private operations). Then potential domain packages (groups of highly coupled classes) are identified using rules based on the types of messages received by the client and server components of the system, and their interfaces exported as Web Services. This is followed by identifying class contracts (i.e. public methods) that are used by classes outside a domain package. The contracts are then combined to reduce the number of candidate Web Services. The final set of service contracts are mapped to Web Services operations, and the input and output parameters of the operations defined using XML schemas. Ambler’s method is an example of a bottom-up Web Service design approach that defines Web Services on top of existing components or objects and is useful for migration to service-oriented architectures. The main focus of this method is grouping of highly coupled classes into coarser components called domain packages, and refining the resulting component interfaces to produce larger grained services that are exported as Web services.
Levi and Arsanjani [2] proposed component-based Web Services design method based on identifying business processes and dividing the problem domain into functional areas based on departmental boundaries, business process boundaries and value chains. The functional areas (i.e. major business areas) are mapped to enterprise components which are then decomposed to identify their constituent business processes creating a goal model using Goal-Service Graphs. The objective of this step is to identify high-level business goals, their sub-goals and services required to achieve the goals. The main benefit of the goal model is that it allows designers to define services based on business needs. The services identified in the Goal-Service Graphs are then assigned to enterprise components that are responsible for providing the services. Service identification involves making decisions about granularity of the services. Next, specifications for enterprise components are created defining the pre and post-conditions for each service and an abstract specification of component behavior. The main focus of this methodology is on designing enterprise components suitable for transformation into Web Services by exporting their interfaces.
Luo et al [3] proposes a methodology for designing Web Services to support enterprise integration projects. The first phase of this method is domain decomposition that identifies relevant functional areas within the problem domain by identifying and modeling business processes. The resulting model is then mapped to Component Business Modeling (CBM) map of the relevant industry domain. Next candidate services are identified based on the inter-component interactions and by grouping business tasks according to components based on the selected CBM. This step is followed by business process realization to ensure that the identified services and components can realize the required business processes. Then the identified services are mapped to the business components that implement the services and business processes, and the service model is created. Identification of services for externalization is based on business alignment, transparency, and service granularity. Finally, the resulting services are fully specified including definition of data input and outputs, interaction models (i.e. synchronous or asynchronous mode of communication), messaging and transport protocols, service composition requirements and non-functional requirements, expressing the specifications using BPEL and WSDL.
Finally, in this category of methods we include the application of Design by Contract (DBC) [4] to the problem definition of service interfaces. Design by Contract is a widely used object-oriented design approach that involves defining interface contracts including pre and post-condition for object methods. DBC is a highly suitable methodology for specifying the Web Services at design time reducing the potential for errors and improving the overall quality of the software development process [5].
1.2. Transformation of Industry Domain Specifications Approaches
Existing industry domain specifications as represented by industry standards (e.g. RosettaNet, embody the domain model for a given industry domain (e.g. travel, healthcare, etc) and provide a good starting point for the design of Web Services. Masud [6] gives guidelines for the definition of Web Services interfaces using WSDL, and Web Services interaction flows using BPEL from existing RosettaNet standards. The methodology describes how relevant information can be extracted from RosettNet PIP (Partner Interface Process) specifications and the corresponding document schemas, and used to define Web Service interfaces and choreography descriptions of the interaction semantics between business partners. Designing Web Services from existing e-business standards enables design of interfaces and interaction dialogues based on industry-wide standard business processes and vocabularies. This avoids the need to define Web Services for individual partner organizations and results in significantly improved interoperability. RosettaNet standard consists of specifications that include dictionaries, Implementation Framework, and PIP specifications. Masud focuses on deriving Web Services interface and choreography descriptions from corresponding PIP specifications and associated Message Structure definitions. The initial phase of the methodology involves definition of Web Services operations and their input and output messages using WSDL. Relevant messages are identified from choreography diagrams and PIP specifications. Next, WSDL message elements based on RosettaNet message definition are defined and corresponding operations specified by mapping messages into operations. The second phase of the methodology deals with creating BPEL descriptions for interactions between trading partners using Web Services defined during the first phase. The methodology uses business process definitions and choreography information defined using UML diagrams and associated tables within the PIP specification as the basis for BPEL specifications. Partner roles defined in PIP are mapped into BPEL, and then the PIP choreography is implemented as choreography of abstract and executable business processes in BPEL.
1.3. Business Process Transformation Approaches
Papazoglou and Yang [7] propose a Web Services development methodology that serves as a framework for business process analysis and service design, and produces service specifications expressed in Web Services Flow Language (WSFL) [8] and service usage interfaces expressed in WSDL. The WSFL service specification describes interaction flows between a set of constituent Web Services that implement a business process (e.g. the travel reservation service provided by airlines), and WSDL service usage interface describes the interface of high-level Web Services that represent the overall business processes. A key component of this methodology is a business process analysis framework used to model constituent services and to define high-level services. During the first phase, the objectives and structure of business processes are identified, grouping and describing activities that implement the corresponding business processes, and defining usage interfaces and relationships between constituent services in WSFL. The second phase is concerned with mapping the constituent services to service provider roles and defining WSDL for the usage interfaces. Another key component of the methodology are service design principles that define guidelines for functional and non-functional aspects of service design. The functional service design considerations include service coupling and service cohesion. Minimization of coupling involves avoiding representational coupling, identity coupling and communication coupling. Increasing service cohesion involves maximizing functional service cohesion, communicational service cohesion, and logical service cohesion [9]. The non-functional service design guidelines identify key design consideration that relate to non-functional aspects of Web Services design and include service provisioning strategies, service policy management models, service programming style (i.e. document centric and RPC centric), and authorization design considerations. The methodology uses both top-down and bottom-up approaches to design interfaces for composite Web Services. Top-down approach is used to analyze business processes and to identify service invocations required to implement each activity within the scope of the process, and the bottom-up approach is used to map existing services provided by external service providers to usage interfaces of the business processes.
Radeka [10] proposes a Web Services design methodology for intra-enterprise Web Services-based application development. The starting point for the method is writing scenarios in plain text to describe the user experience. Then high level business process models are developed based on these scenarios. The process flows help to describe the steps needed to be executed to deliver high-level services. Refining the business model involves maximizing the number process steps that are reused across individual business process diagrams and replacing process steps with corresponding services. Information flows between services are then specified, providing basis for defining service interfaces. The main objective of this methodology is design of sharable component services that can be reused in multiple application contexts.
In summary, while Web Services design and development is an active research area at present there are no widely accepted software development frameworks that can guide designers and developers of Web Services applications. In particular, most methodologies focus on identifying Web Services given a set of application requirements, but do not address the details of definition of service interfaces. We regard service interface design as the key determinant of interoperability and robustness (i.e. application stability when requirements change) of service-oriented applications and we focus on this aspect of Web Services design in our methodology.
2. Web Services Software Development Framework
Similar to the methodology described in section 1.2 above [6] we base our approach on an existing domain standard, the Open Travel Alliance specification (OTA, OTA standard provides a comprehensive specification of business processes, interaction semantics, and data formats for the travel industry domain and avoids the need to perform detailed requirements analysis, providing a starting point for Web Services design. As is the case with most e-business industry domain standards, OTA is a document-oriented specification that relies on document interchange as the basic interoperability mechanism. Such document-oriented standards suffer from a number of important limitations when used directly (i.e. shipping OTA XML documents as SOAP payloads) for the implementation of Web Services applications. These limitations include poor interoperability, limited reuse and extendibility of services [11], [12]. The approach described in this paper transforms the document-oriented OTA specification of message structures into a set of well-defined services using interfaces design principles described in section 2.1 below.
2.1. Web Services Interface Design Principles and Guidelines
The focus of the proposed methodology is on design of service interfaces based on design principles derived from literature on software design, ranging from structured methodologies to more recent object-oriented and component design approaches. We briefly discuss each design principle and how it relates to design of services in the following sections.
Completeness: Application domain functionality should be fully covered by the specified set of services. Incomplete functionality coverage necessitates additional application development, resulting in increased complexity of applications and poor interoperability as additional functionality is not explicitly defined using core services [13].
Minimality: Services should be designed and developed for common (core) functions that provide opportunity for reuse; additional services should be implemented using composition of core services and operations [14], whenever possible. Specialized functions should be supported via an extendibility mechanism [15]. Ensuring minimality of services leads to less complex, more cohesive, and more consistent services.