Web Service Composition Survey: State of the Art ... - IngentaConnect

Recent Patents on Computer Science 2010, 3, 91-107

91

Web Service Composition Survey: State of the Art Review Bassam Al-Shargabi*,1, Alia Sabri2 and Asim El Sheikh3 1

Faculty of Information Technology, Department of Computer Information System, Middle East University for Graduate Studies, Amman, Jordan, 2Faculty of Information Technology, Department of Computer Information System, Jerash Private University, Amman, Jordan, 3Faculty of Information Systems and Technology, Arab Academy for Banking & Financial Sciences, Amman, Jordan Received: December 9, 2009; Accepted: January 29, 2010; Revised: February 17, 2010

Abstract: The Web service composition has received much attention recently to support business-to-business enterprise applications integration. Many composition approaches, languages, platforms, and patents have been proposed to overcome this issue. In this paper we present some of Web service composition languages, platforms, patents, and composition strategies, we compared them to some of the features that must be held by composition process, features such as the dynamic adaptation, execution monitoring, and quality of service (QoS) constraints to satisfy client’s requirements to execute Web process. And we give an outlook to essential future research work. Recent patent and research advances aim to find methods for dynamic learning and redesigning along with monitoring and optimization of Web service composition process to satisfy user constraints.

Keywords: Composition evaluation, dynamic adaptation, service composition, quality of service, web services. 1. INTRODUCTION A web service is a software system designed to support interoperable machine-to-machine interaction over a network. The Web service has an interface described in a machine-processable format. Other systems interact with the Web service in a away prescribed by its description using the Simple Object Access Protocol (SOAP) messages, typically conveyed using HTTP with an XML serialization in conjunction with other web-related standards. This definition was published by W3C [1]. Various techniques for providing product configuration as a web Service were disclosed by Varmaraja et al. [2]. The appearance of web service has created more opportunities for organizations to establish more agile and flexible collaborations with other organizations. And in order to fulfill these opportunities and the requirement of clients we must ensure that functional and Quality of Service (QoS) constraints offered by the Web service provider must be met as they claimed to be in the Web service description. As individual Web services are restricted in their capability, that is why we need to compose existing services to create new functionality to meet the requirements of business processes. Web service composition is the process of combining Web services in order to offer value-added services. Composite services in turn are defined as an aggregation of elementary and composite services as illustrated in Fig. (1). The Web services composition process should satisfy both functional, non-functional requirements and guarantee the correctness of the result. Web service composition is currently an active area of research, with many languages being proposed by academic and industrial research groups due to its complexity. However, the flexibility of compo*Address correspondence to this authors at the Faculty of Information Technology,Department of Computer Information System, Middle East University for Graduate Studies, P.O. Box 42, Amman 11610, Jordan; Tel: +962788614254; E-mail: [email protected]

1874-4796/10 $100.00+.00

sition comes at the penalty of increased system engineering complexity. The complexity of web service composition includes three main factors: (1) the large number of web services that may be available; (2) the different possibilities of integrating web service components into a composite service; (3) various performance requirements (e.g. end-to-end delay, service cost) of a complex service [3]. The advantages of the web service composition are obvious; we can acquire a new enterprise solution by composing web services according to business requirements and reuse existing web services. One can integrate various information systems like Customer Relationship Management (CRM), in appropriate order to support business complex interactions between partners and customers. Unfortunately most of these modeling processes are currently done manually. During the composition of web there are some issues that need to be considered: the composer must preserve a way of predicting the level of QoS of composed services during execution time, and to dynamically redeploy or reconfigure the composed services to maintain the agreed QoS based on user QoS requirements. A dynamic learning and redesigning for Web service composition suggested Chang et al. [4]. In this paper, we present an overview of the proposed Web service composition middleware’s or frameworks, approaches, language standards and patents. We compare them with respect to a set of criteria, such as: managing the QoS constraints for composition of web services at execution time, monitoring the execution of composition of services and the evaluation of composition process, and fault handling. By offering this overview and classification of existing proposals for Web service composition, we hope this research helps researchers to deliver well built solutions. The paper is structured as follows. After this brief introduction, we introduce an overview of Web service composition process in section 2. Then, we present some approa-

© 2010 Bentham Science Publishers Ltd.

92 Recent Patents on Computer Science, 2010, Vol. 3, No. 2

Shargabi and Sheikh

Fig. (1). Web service composition and Execution engine.

ches for web service composition in Section 3. In section 4 we move the attention to dynamic composite service and execution monitoring and their benefits. A selective overview of current Web services languages (BPEL, BPML, WSCI, and OWL-S is presented in section 5). In section 6 we presented some QoS issues to be considered during process of composing Web services. A selective overview of current Web service composition middleware’s or frameworks is presented in section 7. We subsequently compared all these platforms and frameworks with respect to some criteria presented in Section 8. Finally, Section 9 reports some conclusive considerations and some indications for future work. 2. WEB SERVICE COMPOSITION PROCESS The process of Web service composition includes many phases as described by Yang et al. [5], and Orriëns et al. [6] which refers to the service composition life-cycle. The phases include composition definition, scheduling, construction and execution, as illustrated in Fig. (2). The idea behind phased service composition life cycle is to start with an abstract definition and gradually make it concrete to generate executable service processes from these abstract specifications as specified by Orriëns et al. [6]. Definition phase starts with specifying composite service, which specifies the involved Web services that constitutes the composite service and the constraints under which they operate. Scheduling phase of the approach, where the composer system specifies the order and when to execute involved services of composite service. During this phase the system may generate alternative composition schedules and present them to the application developer for selection [6]. Next is the Construction phase to construct an unambiguous composition of concrete services out of a set of desirable or potentially available/matching constituent

Fig. (2). Service composition life cycle [6].

services. Similar to the scheduling phase the system may produce alternative construction schemes (e.g. varying in quality or price) from which the application developer can select. Lastly, during the Execution phase the service composition system prepares the composed services for execution. This phase maps the resulting specification to a standard executable Web service orchestration language (e.g. BPEL see section 5.1) [6]. As the above illustrates the composition life cycle is a structured approach to the process of composing Web services, ranging from definition to execution in order to manage service compositions during the different stages of their lifespan. 3. WEB SERVICE COMPOSITION APPROACHES Web service composition approaches vary from static to dynamic Web service composition which relates to the time when Web services are composed. These are equivalent to design-time and run-time composition. There is also model driven service composition, business rule driven service composition and declarative composition as well as automated and manual service composition. 3.1. Static Web Service Composition Static Web service composition takes place during design-time when the architecture and the design of the software system are planned. The components to be used are selected, joined together and finally compiled and deployed. This may work well as long as the environment of web services and business partners and Web services components do not or only rarely change. Microsoft Biztalk and Bea WebLogic are examples of static composition engines [7]. Two main approaches are currently investigated for static service composition. The first approach is Web service

Web Service Composition

orchestration, binds available Web services by adding a coordinator (the orchestrator) that is responsible for invoking and binding the single sub-activities. The second approach, referred to as web service choreography, does not assume the exploitation of a central coordinator but rather defines complex tasks via the definition of the conversation that should be undertaken by each participant. Following this approach, the overall activity is achieved as the composition of peer-to-peer interactions among the collaborating services as illustrated in Fig. (3). An adaptive orchestration of composite service proposed by Chandra et al. [8], numerous proposals exist for orchestration languages, e.g. BPML (Section 5.2) and BPEL (Section 5.1). And choreography languages e.g. WSCL (section 5.3, WSCI (section 5.4).

Fig. (3). Orchestration and choreography

3.2. Manual Web Service Composition The composition of web services is usually arranged manually. Staring from the process description, composer tries to compose web service. Firstly he/she looks for appropriate Web Firstly he/she looks for appropriate Web services using textual descriptions provided by web service providers in order to understand web service capabilities and their QoS properties. Then he/she connects web services in a suitable order. By matching output parameters with input parameters it can happen that parameters have different data structures and he/she should handle it by finding a transformation mechanism. Such assembling steps are made step by step until achieving the sequence of web services corresponding to the desired business goals [9, 10]. Modeling all these aspects by using a web service composition language like BPEL (Section 5.1) is infeasible to ensure all possible and future situations that can occur during the execution of the process. As well, it is not possible to consider all failures. It is natural that a composer can make errors in the service composition. All these factors do not guarantee that the service composition created

Recent Patents on Computer Science, 2010, Vol. 3, No. 2

93

manually is correctly modeled. The created Web service composition is not flexible to changes in the environment during its execution. One of the composed web services may become unavailable when the composition is enacted, hence the service composition should be immediately rebuilt by the composer. Therefore, there is a need for fast adaptive approaches for modeling of a service composition. For this reason semi-automated and full-automated approaches for the web service composition are strong research topics now as noted by Hüttenrauch et al. [10]. 3.3. Semi-Automated Web Service Composition The major motivation of semi-automated method is to support users in creating a web service composition by giving the opportunity to filter, select web services and by providing intelligent plans. The composer should be able to assess a partial service composition created by the user, notify the user of issues that have to be resolved in the current situation and suggest to the user what actions could be taken next [10]. By making a service composition the user may use different strategies: 1) top down selection of components, for instance, the user does not have an explicit description of the desired result, they may start making a composition from abstract model and then specify it; 2) result-based selection of components, the user has an explicit description of the desired result and would like to simulate the situation that leads to this desired result; 3) situation-based selection of components, the user has only a description of initial states and wants to get a simulating model that describes possible results [10]. To perform abovementioned tasks semiautomated web service composition tools and methods provide service discovery, matchmaking tasks in automatic way and leaves difficult tasks of control and data-flow linkages for the user. Service discovery can be performed by using service repositories like UDDI. It gives the possibility to register and advertise web services in order to be discovered by service requestors. Since the number of potential services may be huge in the repository, we need matchmaking mechanisms capable to find a proper service by using semantic descriptions. For this purpose semantic descriptions are used that provide meanings for agents so that they can reason about web services to perform automatic web service discovery, execution and composition e.g. OWL-S (Section 5.5). 3.4. Fully-Automated Web Service Composition In the fully-automated Web service composition, web service discovery, matchmaking and execution are performed automatically. Where the human factor as a bottleneck is removed and web service composition is made on demand at each case and automatically adapted to the current state of the world. Fully-automated Web service composition may be used not only for the creation of the initial web service composition, but for fault handling by re-planning of Web service compositions which have been already enacted. However, by automated composition, the end user or application developer specifies a business goal (e.g. expressed in a description language or in a mathematical notation) and an intelligent composition engine selects adequate services and


offers the composition to the user in a transparent way [11]. A system and method for automatic web service composition based on syntactic and semantic rules presented by Chua et al. [12]. The main problems are how to identify Web candidate services, how to compose them, and how to verify how closely they match a request. Web service composition languages should enable the representation of semantics of composed services, in order to facilitate the automated composition of services [10]. 3.5. Model Driven Web Service Composition Model driven web service composition was introduced in 2003 by Orriens et al. [13], which is based on dynamic service composition, since it should facilitate the management and development of dynamic service compositions. UML (Unified Modeling Language) is used to provide a high level of abstraction, and to enable direct mapping to other standards, such as BPEL (Section 5.1). The OCL (Object Constraint Language) is used to express business rules and to describe the process flow. Business rules can be used to structure and schedule service composition, and to describe service selection and service bindings. Orriens et al. [13] identifies two main use cases: the process of service composition development, which may be sub-divided into the four phases of service definition, scheduling, construction, and execution. In order to enable representation of all possible service compositions, it also introduces an information model [13]; an abstract metamodel that models components and relationships between the components. For that purpose, service composition elements and service composition rules are defined [9]. 4. DYNAMIC COMPOSITION OF WEB SERVICES & EXECUTION MONITORING Dynamic web service composition takes place during run-time when the environment is a very flexible and dynamic environment. One of the major benefits of ServiceOriented Architecture (SOA) is that it enables dynamic service binding, which allows web service users to discover, select and invoke web services at run-time. New Web services become available on a daily basis and the number of service providers is constantly growing. Ideally service processes should be able to transparently adapt to environment changes and to adapt to customer requirements with minimal user intervention. Dynamic composition of web services aims at composing web services that satisfy a given service request from an end-user or service developer. Web services are composed of existing atomic web services, which are orchestrated in the Web service composition. In order to execute a composite service at run time according to Benatallah et al. [14] there are two different execution models as follows: Centralized In this model (Orchestration), the task for coordinating the execution of a composite service is based on a single coordinator as described by Sun et al. [7]. This coordinator communicates with each of the web services by sending and receiving messages (SOAP messages). This is similar to

Shargabi and Sheikh

traditional workflow management systems as defined by Van der et al. [14, 15]. Peer-to-Peer (Choreography) In this model, the task for coordinating the executions of a composite service is circulated among Web service providers of the web services as in SELF-SERV which presented by Benatallah et al. [16]. The execution environment of Web services composer will become a form of interconnected services through agreement protocols, which have some similarities with distributed workflow execution models. It is critical that a means is provided for monitoring the executions of a composition of Web services, in order to be able to trace the execution of a composition of Web services which is essential for customer feedback, adaptation during execution, and service enhancement. The monitoring techniques vary depending on the execution model. In the case of centralized execution, the central composer can maintain information of execution traces. In the case of peer-to-peer execution, however, the information about composed Web services executions is scattered across a number of distributed data sources hosted by the providers of the Web services. Accordingly, it is necessary either to consolidate these distributed data sources periodically or to be able to answer queries on demand. According to Benatallah et al. [14], a link with a Web service is dynamic when a mechanism selects, at runtime, the actual Web service that will be invoked to perform a given step in the composite service execution. This is called a dynamic service selection. The pool of candidate Web services over which the dynamic selection occurs may be: (i) Determined at design time; (ii) Obtained by evaluating a given query over a registry (for example, UDDI registry); or (iii) Obtained from an invocation to a brokering service. The selection itself is then performed based on a set of requirements and using a set of preferences expressed in the composite service description. These constraints and preferences may involve both functional attributes (that is, attributes describing the capabilities of the services) and nonfunctional attributes (for example, time, location, price, reliability, trust).Once a Web service within the pool of candidate Web services is selected, it has to be invoked by the composite service. This implies that also all the candidate Web services for a given task of a composite service offer exactly the same interface (that is, the same set of operations and common constraints on their use) or that some late binding mechanism is used to “homogenize” the interfaces provided by all services so that at the end, the composite service can invoke any of these candidate service [14]. Although during the execution of a composite service, some Web services may update their QoS properties others may become unavailable, so, approaches where Web services are statically composed are inappropriate. Monitoring execution of composite service is needed during run-time due to the changes in the QoS of the component services that are taken into account. Thus a dynamic web service composition, execution, and monitoring is needed. Much research work has been done to achieve the openness and dynamics of web service composition by Zeng et al. [17], Zeng et al. [18]; Berardi et al. [19]. The Web services


composition platform, StarWSCoP (Star Web Services Composition Platform), is introduced by Sun et al. [7]. It focuses on dynamic web services composition. The composition consists of four steps: •

Service providers publish their services at a Web service registry

•

The Service Composition Engine decomposes user requirements into an abstract service and sends a SOAP request to the registry to find the proper services

•

The web service registry returns a set of concrete services

•

The service composition engine sends a SOAP request to the concrete services and binds to them.

4.1. Benefits of Dynamic Web Services Composition There are numerous benefits of the dynamic composition of web services. Unlike static composition, where the number of web services provided to the end users is restricted and the web services are specified at design time, dynamic web service composition can serve applications or users on an on demand basis. With dynamic web service composition, an unlimited number of new web services can be created from a limited set of service components. Besides, there is no need to keep local information of available web services in order to create composite web services as is the case with most of the static-based composition techniques. Moreover, the application is no longer limited to the original set of operations that were specified and envisioned at the design or run-time. The capabilities of the application can be extended at run-time. Also, the customization of application based on the individual needs of a user can be made dynamically through the use of dynamic composition without affecting other users on the system [20]. Dynamic composition infrastructure can be helpful in upgrading an application. Instead of being brought offline and having all services suspended before upgrading; users can continue to interact with the old services while the composition of new services is taking place. This will provide seamless upgrading, round-the-clock, of service capabilities to existing applications [21]. Tentatively, it should be clear that dynamic composition is much more expensive in terms of computational power and CPU time than static composition, as they require more complicated algorithms and procedures. However, this is not necessarily true all the time, since it is closely related to the application requirements/specifications and the user’s needs. There have been several benefits to dynamic service composition as noted by Mennie et al. [20] and Dustdar et al. [9]: •

Greater flexibility-the customization of software, based on the individual needs of a user, can be made dynamic through the use of dynamic composition without affecting other users on the system.

•

New services can be created at runtime-the application is no longer restricted to the original set of operations that were specified and envisioned at the design or compile times. The capabilities of the application can be extended at runtime.

Recent Patents on Computer Science, 2010, Vol. 3, No. 2

95

•

Users are not interrupted during upgrades of applications instead of being brought offline and having all services suspended before upgrading, through the dyna-mic composition infrastructure, users can continue to interact with the old services while the composition of new services is taking place. This will provide continuous and seamless upgrading of service capabilities to existing applications.

•

Unlimited set of services-unlike static composition, where the number of services provided to end users is limited and the services are specified at design time, dynamic composition can serve applications or users on an on demand basis. With dynamic composition, theoretically an unlimited number of new services can be created from a limited set of service components [21]. A system and a method to generate dynamic web services was provided by Baikov et al. [22] and for dynamic web service composition provided by Plutowski et al. [23] along with a reference model by Eid et al. [24].

5. WEB SERVICE COMPOSITION LANGUAGES Composite services are modeled as business processes enacted by a service process engine. The fact that industry is aware of the opportunities brought by web service composition lead to the development of many languages for the composition of web services, such as BEPEL, WSCI, WS-CL, and OWL-S. In the next subsections we will discuss the features of these composition languages. 5.1. BPEL The Business Process Execution Language for web Services (BPEL4WS or BPEL) is the product of the union of WSFL and XLANG, which is an XML-based language proposed to enable portable business process definitions for WSDL-based business processes as defined by Alonso et al. [25]. BPEL describes business process as executable or abstract processes. Executable processes describe how processes can be executed by BPEL; Abstract processes define only how the message exchanged between parties, without including the specific details of process flow. BPEL defines a model and a grammar for describing the behavior of a business process based on interactions between the process and its partners. The interaction with each partner occurs through web Service interfaces, and the structure of the relationship at the interface level is encapsulated in what we call a partner link. The BPEL4WS process defines how multiple service interactions with these partners are coordinated to achieve a business goal, as well as the state and the logic necessary for this coordination. BPEL4WS also introduces systematic mechanisms for dealing with business exceptions and processing faults. Finally, BPEL4WS introduces a mechanism to define how individual or composite activities within a process are to be compensated in cases where exceptions occur or a partner requests reversal [6]. BPEL process defines the roles involved in a composition as abstract processes. A buyer and a seller are examples of two roles. They are expressed using partner link definitions. We can have a role for each Web service that is


composed and does some activity. In order to integrate services, they are treated as partners that fill roles as prescribed by Mandel et al. [26]. A simple BPEL process is shown in Fig. (4). This process returns a string parameter back to the client whenever the operation echo is called. It consists of a activity that contains two basic activities. The activity specifies that the process must wait until the client calls the operation echo. The activity specifies that the process has to send the message contained in the variable request to the client as presented by Charfi et al. [27]. In summary, business process is used to create an organizer that point to each service endpoint that will be actually executed. BPEL has inadequate support for changing the composition at run-time.

Fig. (4). Simple BPEL process [27].

5.2. BPML Business Process Modeling Language (BPML) is developed by BPMI.org (the Business Process Management Initiative). BPMI.org is supported by several organizations, including Intalio, SAP, Sun, and Versata. BPML provides an abstract model for expressing business processes and supporting entities as defined by Arkin [28]. BML models both executable and abstract processes that address all aspects of business processes, including activities of varying complexity, transactions and their compensation, data management, concurrency, exception handling and operational semantics [6]. BPML offer the arrangements of how activities should be executed. BPML activities defined as components performing specific functions. Activities in BMPL are simple activities and complex activities. Simple activities are atomic while complex activities are decomposed into smaller activities. A process is a complex activity which can be invoked by other processes. Besides the ability to define activities and processes, BPML uses properties to maintain state. These properties are contained in contexts, which define an environment for the execution of related activities. Thus, activities use their context to exchange information and coordinate execution. For the latter purpose signals are used, e.g. to synchronize the start of one activity with the completion of another activity. Signals are also used to reflect conditions that arise from the execution of activities, and to allow other activities executing in that context to detect and

Shargabi and Sheikh

react to these conditions. Lastly, exception processes and fault handlers can be used in a context to handle exceptional behavior during execution [6]. As is apparent from the above, BPML proposes a rather limited model for defining service compositions. Although it is true that BPML was not developed specifically for this purpose, there are still a number of things missing that are required not only for service composition, but for business processes as well [20]. For example, concepts like roles and providers are not defined at all. Other semantics, such as the separation of the notion of activity and the service that implements that activity, are also not supported. As such, BPML is capable of expressing the execution of more programmatic-like activities, but is not suitable for composing web services in order to realize business processes. This is very likely the main reason, in conjunction with the rising popularity of BPEL that the support for BPML has diminished. Example of this is that SAP (one of the main supporters of BPML) switched to BPEL [6]. 5.3. WSCI The web Service Choreography Interface (WSCI) has been developed by Sun [29]. It is an XML-based interface description language that aims to describe the flow of messages exchanged by a web service participating in choreographed interactions with other services [6]. WSCI describes the dynamic interface of the Web service participating in a given message exchange by means of reusing the operations defined for a static interface (currently based on WSDL). More specifically, WSCI attempts to describe the observable behavior of a web service in terms of temporal and logical dependencies among the exchanged messages, featuring sequencing rules, correlation, exception handling, and transactions. It can also describe the collective message exchange among interacting web services, thus providing a global, message-oriented view of the interactions. In order to support the above, a WSCI interface describes the behavior of a Web service in terms of choreographed activities. Activities may be atomic or complex, i.e. recursively composed of other activities [6]. Choreography describes temporal and/or logical dependencies among activities. Atomic activities represent the basic unit of behavior of a web service, which correspond to the execution of operations defined in static service definition languages such as WSDL. In order to maintain the information that used by activities, the WSCI uses properties as reference ”values”. Furthermore, correlations between properties can be defined. Similar to BPML these properties are contained in a context, which describes the environment in which a set of activities is executed. A context can also be associated with exceptional and transactional behavior, just as is the case in BPML [13]. An example of WSCI process is shown in Fig. (5), when customer ordering a trip, Travel agency Web service books the seats on the plane by contacting the airliner Web service, travel agency web service sends a statement back to the customer [28]. WSCI is targeted at describing the interface of each partner in a choreography of services and how the partners can and will react to things. As such, WSCI is asymmetric in the sense that it is designed from the perspective of one side of the collaboration.
