There are several research initiatives in the field of service composition. This section introduces some representative work in four areas of service composition respec-tively, which are the framework of service composition, service composition plan generation, service selection and plan optimization, and multi-agent based service composition.
3.3.1 Framework of Service Composition
In survey [10], three approaches of building a composite service are discussed, namely peer-to-peer approach, mediated approach and brokered approach.
Peer-to-peer is the most general situation in which all services are essentially equal and any pair of peers can communicate with each other directly. Mediated ap-proach is based on a “hub-and-spoke” topology, where one service plays a special role called the process mediator and the other services can communicate with the mediator but not with each other in terms of both the control and the data sharing.
The mediator coordinates the activities of other services. The widely used languages such as BPEL4WS are designed for specifying the behaviors of the mediator. In the topology of the mediated approach, all “leaves” are atomic services. Some or all of the leaves can be composite services mediated. Assuming that the new mediator is linked to exactly one service from each of the existing composite services, this will lead in most practical cases to a composite service whose topology is a tree.
A variation of the mediated approach is the brokered approach, where the process control is centralized but the data can be passed between any pair of the peers di-rectly. QBroker, suggested in [27], is a broker-based architecture, which provides the end-to-end QoS management for distributed services and some functions including service discovery, planning, selection and adaptation.
3.3.2 Service Composition Plan Generation
The service composition plan should include details such as the list of participant services, their execution order, the way they are interconnected and the mappings between their messages. How is a service composition plan generated? There are two types of method [22]: business-flow-based and semantics-based. The first ap-proach is primarily syntactical: web service interfaces are like remote procedure calls and the interaction protocols are manually written. The semantic web commu-nity focuses on reasoning about web resources by explicitly declaring their precon-ditions and effects with terms precisely defined in the ontology. For the composition of web services, they draw on goal-oriented inference from planning. So far, both approaches have been developed rather independently from each other.
Service composition based on the business flow is adopted by industry. This method uses Web Service Definition Language (WSDL) to describe the interface of web service. The interactions and message exchanges between the services are described in a business protocol specification language, which specifies the roles of each of the partners and the logical flow of the message exchanges. The language includes BPEL4WS proposed by IBM and Microsoft. The most difficult task for an IT specialist is to specify the logic of the message flow. For this purpose, BPEL4WS provides programming-language like constructs (sequence, switch, while, pick) as well as graph-based links that represent additional ordering constraints on con-structs.
Semantics-based service composition uses the concepts of service ontology to describe the meaning of services and identify the synonyms. For example, the laptop service and the notebook service are of the same semanteme. Consequently, they may provide the same service. Service ontology consists of a common language agreed by a domain. It defines a terminology that is used by all participants in that domain. Within a domain, service providers describe their services using the terms of the domains ontology, while service customers use the terms of the ontology to formulate queries over the registry of the domain. Ontologies described in languages such as OWL [21] and DAML [9] can be completely interpreted by machine. In the condition that the machine can understand services, it can make use of artificial intelligence approaches to compose services in terms of the service composition plan.
3.3.3 Service Selection and Plan Optimization
Requirements for a composite service from customers are important for most practi-cal distributed applications. For example, a customer may need a real-time response while another customer may prefer cost to the execution time. Therefore, besides functional properties, the end-to-end QoS of a composite service should be consid-ered. In general, services with similar and compatible functions may be offered at different QoS levels. Thus, the decision must be made to select component services
at appropriate QoS levels in service composition [28] and a QoS-aware algorithm to select services is needed to optimize the service composition plan. A variety of approaches are suggested to solve the problem of service selection. Representative works include using heuristic algorithms [19, 28], integer programming [29] and genetic algorithms [13, 30].
In [28], Yu et al. design a broker-based architecture called Qbroker to facilitate the selection of QoS-based services. The objective of service selection is to maxi-mize an application-specific utility function under the end-to-end QoS constraints.
The problem is modeled in two ways: the combinatorial model and the graph model.
The combinatorial model defines the problem as a Multi-dimension Multi-choice 0–1 Knapsack Problem (MMKP). The graph model defines the problem as a Multi-Constraint Optimal Path (MCOP) problem. Efficient heuristic algorithms for service processes of different composition structures are presented in this chapter.
In [29], AgFlow is presented as a middleware platform that enables the QoS-driven composition of web services. In AgFlow, the QoS of web services is eval-uated by means of an extensible multi-dimensional QoS model, and the selection of component services is performed in such a way as to optimize the QoS of the composite service. Furthermore, AgFlow adapts to changes that occur during the execution of a composite service by revising the execution plan in order to conform to the customers constraints on QoS. The salient features of AgFlow include two alternative QoS-driven service selection approaches for the composite service exe-cution: one is based on the local (task-level) selection of services and the other is based on the global allocation of tasks to services using integer programming.
3.3.4 Multi-Agent Based Service Composition
Up to now, multi-agent based service composition also appears in the literature.
Agent based systems facilitate the deployment of a widely distributed architec-ture, with high capabilities for communication and negotiation among all the com-ponents. Because the agent characterizes autonomy, social ability, reactivity, pro-activeness and mobility, it has been introduced to build a composite service. During the composition process, agents engage in conversations with their peers to agree on the services that participate in this process. Mobile agents can represent the cus-tomer or the main web service, and navigate around the network to contact interest-ing services.
Maamar et al. [14] put forward an approach for service composition based on agents and context. In their paper, three types of agents have been suggested, namely composite-service-agent associated with composite services, master-service-agent associated with web services and service-agent associated with service instances.
The different agents are aware of the context of their respective services in the ob-jective to devise composite services on-the-fly. LEAP is a project supported by Eu-ropean Commission, in which a multi-agent based architecture model for service composition is developed [2]. Its main feature is a set of generic services that are
implemented independently of agents and can be installed into agents by the appli-cation developer in a flexible way. Therefore, services plugged into agents can be composed on the multi-agent platform. Moreover, two applications using this archi-tecture model are also developed within the LEAP project. Their application domain is the support of mobile, virtual teams for the German automobile club ADAC and for British Telecommunications.