Dynamic Self-healing for Composite Services using. Semantic Web Service Technology

Transcription

1 Dynamic Self-healing for Composite Services using Semantic Web Service Technology By Wei Ren (B.Eng., M.Eng., Tianjin University, P.R. China) School of Information and Communication Technology Science, Environment, Engineering and Technology Griffith University Submitted in fulfillment of the requirements of the degree of Doctor of Philosophy July 2009

2 Abstract Abstract Service-Oriented Architecture (SOA) has emerged as a promising paradigm for building loosely coupled, standard-based and Web-enabled distributed applications and systems. The essential notion and technology of SOA is Web service which is the high level of abstraction of functionality with well-defined interfaces. If a Web service is further equipped with well-defined semantics, it is termed Semantic Web service. With the power of Semantics of Web services, SOA has created many new opportunities to meet the challenge of enterprise integration and provides great potentials for automated integration. However, this promising paradigm has also imposed a great challenge to the service discovery, invocation, composition, selfhealing capability and so on. Among all those issues, service composition, which is defined as aggregation of other services to provide a more sophisticated, value-added service, is at the core of many applications of Web services. From a service oriented perspective, application integration which is a long standing issue in industry can be achieved via service composition. Nevertheless, the dynamics in real application context when addressing the service composition very much complicate the matter, and it is often desirable to accomplish composition with high degree of serviceability, especially when environment changes or when services previously used becomes unavailable. One of approaches to serviceability is the capability of self-healing with less or no external interventions when changes occur. Service composition and self healing of composite services are the major concerns of the research work described i

3 Abstract in this thesis. The main objectives are to extensively explore semantics for facilitating Web service composition and for realizing dynamic self-healing for composite services in a semantic-enhanced service-oriented manufacturing Collaborative Virtual Enterprise (CVE). A CVE is a temporary alliance of enterprises to share skills or core competencies and resources in order to better respond to business opportunities in a more collaborative rather than competitive manner. Dynamism is a salient feature of CVE. A CVE needs to be dynamically formulated, its business processes need to be dynamically configured and executed to respond to the dynamic market. A CVE needs to quickly integrate its systems, applications, and services to fulfill its business goals. Taking semantic Web service-oriented approach, we shall first establish a semantic rich service-oriented manufacturing CVE where a collection of Semantic Web services are developed. Within the service-oriented paradigm, two different approaches BPEL and OWL-S are investigated to realize service composition in a service-oriented manufacturing CVE. The critical analysis of BPEL and OWL-S is conducted in the manufacturing CVE scenario. Five key criteria for evaluating technologies of service composition are identified. Moreover, semantic-driven services composer based on OWL-S is developed and the goal-oriented forward-chaining algorithm is presented. In order to systematically address semantic web service composition, a business rule enhanced semantic service composition framework is further presented and analyzed. ii

4 Abstract We adopt the divide-and-conquer strategy and propose a hierarchical composition architecture to handle tasks of complex service composition. In this framework, the description of each Web Service is enhanced with rule-based modeling of the essential business logic behind the service interface. A formal notion of service utilities has been provided. Complete processes for calculating the service utilities have also been introduced through processing and evaluating these business rules. A PC manufacturing CVE derived from a practical industrial setting is designed and a prototype system is developed to experimentally evaluate the effectiveness of our service composition framework. In a practical industrial setting, the effective and efficient service composition is often not sufficient for dynamic natures of CVE. Once formulated, a composite service for a business goal must be able to address many dynamic changing issues, and in this case self-healing capability of a composite service has appeared as an attractive approach. Self-healing refers to a capability of a service to maintain its serviceability by healing itself when its component service becomes unavailable or downgraded. In this research, a self-healing capable composite service execution system is proposed. The execution system takes advantage of the complementary strengths of OWL-S and BPEL in the following ways: (1) a dynamic self-healing mechanism is proposed which can dynamically identify suitable alternatives and replace faulty services such that a composite service can be performed successfully despite of unexpected exceptions; (2) an OWL-S process to BPEL process Mapper is presented which can translate OWL-S process to BPEL process and meanwhile embed the self-healing iii

5 Abstract mechanism into BPEL workflow. Semantic Web service technology plays its part for service matching and selection during the self-healing process in a sense that Semantic Web services are equipped with rich business rules in a domain-dependent manner. A concrete scenario PC manufacturing CVE is used to demonstrate the effectiveness of self-healing capable composite service execution system. iv

6 GRIFFITH UNIVERSITY Date: July 2009 Author: Title: Element: Wei Ren Dynamic Self-healing for Composite Services using Semantic Web Service Technology School of Information and Communication Technology Degree: Ph.D. Year: 2009 I declare this work has not previously been submitted for a degree or diploma in any university. To the best of my knowledge and belief, the thesis contains no material previously published or written by another person except where due reference is made in the thesis itself. Signature of Author v

7 Table of Content Table of Content Abstract... i Table of Content... vi List of Figures... xi List of Tables... xv Acknowledgement... xvi 1 Introduction Motivation Research goals Contribution Thesis outline Preliminaries Web Services SOAP WSDL UDDI Semantic Web Ontology Rule Semantic Web Services WSDL-S WSMO vi

8 Table of Content OWL-S SAWSDL Related Work Web service composition Semantic Web service matching Semi-automatic service composition AI based service composition Semantic-based service composition QoS aware service composition Others Self-healing for composite service Autonomic computing systems Self-healing system Self-healing in SOA Semantic Rich Service-oriented Manufacturing CVE Traditional manufacturing enterprise Manufacturing overview Manufacturing workflow Service-oriented manufacturing CVE Service Virtualization WSDL service description Web service implementation Semantic rich service-oriented manufacturing CVE Semantic Web Services for manufacturing CVE vii

9 Table of Content Automatic execution of OWL-S service Framework of automatic execution of OWL-S Service Summary Web Service Composition Service-oriented Integration Architecture Strategies of service composition WSBPEL approach OWL-S approach Characterizing Services Composeability Architecture of the semantic-driven service composer Service Composition Algorithm Composite Sequence generating Algorithm Comparison study Service Composition Requirements A Scenario High level service process in service-oriented manufacturing CVE Comparison Component Model Orchestration Model Data and Data Flow Model Error Handling and Compensation Quality of Service (QoS) Summary Business Rule Enhanced Semantic Service Composition Framework viii

10 Table of Content 6.1 Hierarchical service composition framework Service selection and composition using business rule Definition of Service Utility Business rules enhanced service description Local Utility evaluation Global Utility evaluation Service Selection Algorithm System prototyping and experiment Scenario System Prototyping Service Selection Experimentation Summary Dynamic Self-healing for Composite Service with Semantic Web Services Concept for self-healing Self-healing capable composite service execution system System architecture Self-healing mechanism and its application in PC manufacturing CVE Self-healing mechanism Service discovery Knowledge base update Rule evaluation and rule driven service selection Service invocation Self-healing mechanism in a PC manufacturing CVE ix

11 Table of Content Service discovery Knowledge base update Rule evaluation and rule driven service selection Service invocation OWLS2BPEL Mapper Background OWL-S composite service to BPEL process Mapper Syntactic mapping Semantic mapping Scenario analysis Summary Conclusion and Future Work Summary Contribution Future work Appendices Bibliography Publications derived from this research x

12 List of Figures List of Figures Figure 1.1 Semantic Web service network... 8 Figure 2.1 Architecture of the Semantic Web [Taken from (Berners-Lee, 2003)] Figure 2.2 The main elements of WSMF Figure 4.1 Manufacturing overview Figure 4.2 The simplified manufacturing workflow Figure 4.3 Service virtualization for manufacturing CVE Figure 4.4 WSDL description for Issue Purchase Order Web service Figure 4.5 XML schema for Issue Purchase Order Web service Figure 4.6 OWL-S: an upper ontology for Semantic Markup for Web Service Figure 4.7 Ontology for information flow of manufacturing CVE Figure 4.8 Partial view of ontology Figure 4.9 OWL-S description for IssuePurchaseOrderService Figure 4.10 Semantic Web services for manufacturing CVE Figure 4.11 OWL-S and WSDL mapping mechanism Figure 4.12 Framework of automatic execution of OWL-S service Figure 5.1 The service-oriented integration architecture for CVE Figure 5.2 Sub-workflow in manufacturing CVE xi

13 List of Figures Figure 5.3 BPEL process for Process Product Purchase Order service Figure 5.4 BPEL source code for Process Product Purchase Order service Figure 5.5 BPEL process for sub-workflow in manufacturing CVE Figure 5.6 A composite service execution sequence Figure 5.7 The semantic-driven service composer Figure 5.8 The forward-chaining service composition algorithm Figure 5.9 The composite sequence generating algorithm Figure 5.10 The composite service sequence obtained through the services composer Figure 5.11 High level service process in an manufacturing CVE Figure 5.12 Plan Schedule Composite Service Figure 5.13 Top level of the OWL-S service ontology [Taken from (OWL-S Coalition 2004)] Figure 5.14 An example of Control Flow in BPEL Figure 5.15 An example of Control Flow in OWL-S Figure 5.16 An example of Data Flow in BPEL Figure 5.17 An example of Data Flow in OWL-S Figure 5.18 An example of Fault handlers in BPEL Figure 6.1 A high-level view of the manufacturing-centric business process Figure 6.2 A hierarchical service composition framework Figure 6.3 SWRL description for rule R xii

14 List of Figures Figure 6.4 Local utility evaluation Figure 6.5 Global utility evaluation Figure 6.6 A service selection algorithm for constructing composite services with high global utilities Figure 6.7 Partial view of a PC Manufacturing CVE Figure 6.8 System Architecture Figure 6.9 User Request Figure 6.10 Executable composite service details Figure 6.11 Search performance Figure 7.1 Self-healing capable composite service execution system Figure 7.2 Scoped fault handling Figure 7.3 Matching algorithm Figure 7.4 Ontology for self-healing Figure 7.5 Self-healing procedure Figure 7.6 Generated self-healing service flow Figure 7.7 WSDL description of Service Discovery WS Figure 7.8 Part of composite service in PC manufacturing CVE Figure 7.9 Partial domain ontology Figure 7.10 Created instances in knowledge base Figure 7.11 SQWRL description for global business rule R xiii

15 List of Figures Figure 7.12 OWL-S to BPEL Mapper Figure 7.13 OWL-S/WSDL Grounding Figure 7.14 URL of rule file in ServiceParameter of OWL-S profile Figure 7.15 Control constructs mapping Figure 7.16 Rule Evaluator Web service Figure 7.17 KB Update Web service Figure 7.18 Semantic Web service mapping Figure 7.19 Scenario analysis xiv

16 List of Tables List of Tables Table 4.1 Processes in Service-oriented manufacturing CVE Table 5.1 The four degrees of semantic matching (Paolucci et al. 2002) Table 5.2 The newly added outputs to S outputs during each forward-chaining round 102 Table 6.1 Monitor Price of Services W1 and W Table 6.2 Percentage of optimum and Variation xv

17 Acknowledgement Acknowledgement I would like to take this chance to thank peoples who have supported, directed and assisted me along the way. First of all, I would like to express my deepest and sincerest gratitude to my supervisors, Dr. David Chen, Prof. Chengzheng Sun and Prof. Wentong Cai, who gave me the opportunity and support to work in this project. Their understanding, encouraging and personal guidance have made this research possible. My deepest thanks also go to my advisor, Prof. Zhonghua Yang, who offered the opportunity of working with him and provided an excellent research environment in which the guidance and supports are always made available for me whenever I am in need in the past three years. I would like to express my heartfelt gratitude for Dr. Gang Chen who helped me in every aspect of my research, and provided guidance, inspiration, and untiring help during my difficult moments. I am also grateful to Dr. Rong Zhou for helping me clarify my thoughts through many meetings and for helping me format my thesis. To my family my husband, my lovely son and my parents, the most important people in my life, I also want to say thank you for your tremendous support that you have provided in many ways during my research. Thank you for reminding me daily about what is truly important in life which has pushed me to carry on. xvi

18 Chapter 1: Introduction 1 Introduction 1.1 Motivation In the 21 st century, business moves at an ever faster space. Increasing number of companies move their business operations to foreign countries by going global for different reasons. First, in order to stay ahead of the competition, companies move as quickly as possible to secure a strong position in some of the emerging markets. They establish operations there and manufacture products customized for the need of the people in such areas. Second, some of the developing countries that need capital infusion, skills, and technology provide incentives such as tax exemptions, subsidies and low wages, etc. These attractive incentives can significantly increase profits and reduce cost for these companies. Third, technological advances not only dramatically lower the costs of transportation, communication, data processing and information storage and retrieval, but also make them faster than ever before. Fourth, economic liberalization led to reduced trade protection and to a more liberal world trading system. As a result, tariffs and other barriers to trade in goods and services have been significantly reduced. And finally is the higher consumer demand and expectation. Consumers nowadays have been used to getting what they want, right when they want it. They increasingly expect customized goods and services tailored to their unique taste. 1

19 Chapter 1: Introduction Moving toward a borderless world, globalization integrated markets on a worldwide basis and facilitated greater openness in the international economy. However, the increasing globalization still faces a lot of challenges such as ever-quicker response time to shifting demands, collaboration with new partners from different countries to fulfill a common business goal and competition with other companies which have the similar functionalities. To meet new challenges, today s companies need to be more agile, adaptable and flexible than ever before and quickly response to changes on a worldwide scale. With Internet technology, there is no boundary of state or country in this new world. Every company needs to keep up with their competitors, quickly respond to and in some cases anticipate in advance the shifting market demands. In order to survive in this new and open economy, speed and variety is the key. Companies must work with people, different companies, and countries around the world in the form of strategic alliance to ensure sustained competitive advantage. Companies must participate in adaptive business network, linking standard business processes and common technology that allows them to work together as a loose network of partners (Heinrich, 2003). Most importantly they must adapt to changing market conditions. Agile business practice will become a core requirement for conducting business in future (Swamidass, 2002). As a result, the trend of globalization leads to a new paradigm shift in industry that companies increasingly focus on their core competencies and outsource all other 2

20 Chapter 1: Introduction functions, formulating a virtual chain of enterprises. A Collaborative Virtual Enterprise (CVE) is a temporary alliance of enterprises to share skills or core competencies and resources in order to better respond to business opportunities in a more collaborative manner. Within this virtual enterprise, companies actively participate in collaboration, and therefore, they are more agile to meet changing market demands. Particularly, a manufacturing CVE needs agility, dynamicity and flexibility in manufacturing processes and workflows in order to maintain customer satisfaction and profitability even under the condition of change of product & service requirements and market uncertainty. Effective collaboration in CVE relies on the computer networks and IT technologies to provide the desirable dynamism and flexibility. Business processes in a CVE need to be dynamically formulated, configured and executed to respond to the dynamic market. A CVE needs to quickly integrate its systems, applications, and services to fulfill its business goals and to maintain its competitive edge and market dominance. Integration is the ability to easily expand an operation to incorporate a wider range of products or process technologies (Swamidass, 2002). Enterprise integration is a long standing issue in the industry. Typically, it is the process of integrating multiple IT-related services and facilities that were independently developed, may use incompatible technology, and remain independently managed, including the applications, processes, various data sources, and legacy systems. For decades, enterprise integration for manufacturing has been 3

21 Chapter 1: Introduction notoriously complex and challenging. In general, there are three conventional approaches to enterprise integration: data centric approach, process-oriented approach, and message-oriented approach. All these approaches and attempts have relied on proprietary APIs and library-call-like interactions, requiring a high degree of coordination. They do not address the interoperability issue between heterogeneous systems. The emerging of Web services and Semantic Web services opens the new opportunities for enterprise collaboration and automated integration. Many of the concepts for Web services are rooted in a conceptual architecture called Service- Oriented Architecture (SOA). SOA is an architectural style and a combination of methodologies that aims to achieve interoperability between diverse applications by utilizing reusable services. Since SOA is a concept independent from any certain technology, it is likely to implement SOA in enterprise in variety of ways. For instance, the initial SOA implementations use technologies such as CORBA, COM/DCOM and RMI. Nowadays, building SOA with Web services technology are gaining momentum for building loosely coupled, standard-based and Web-enabled distributed applications and systems. The central notion of SOA is the service that refers to a network-enabled entity delivered over Web using XML-based technologies (Booth et al. 2004). Services provide the highest level of abstraction and support the right kind of programming model for open distributed systems in the following ways: 4

22 Chapter 1: Introduction Services are network-enabled components with well-defined interfaces that are implementation independent. Services are consumed by message exchange and clients are not concerned with how these services will execute their requests. Services are self-contained to offer functionality as defined in interfaces. Services can be dynamically discovered. Services are loosely coupled, and thus more independent. Composite services can be built from the aggregate of other services. Web service-oriented approach provides a standard-based higher level of abstraction than conventional message oriented approach. It standardizes various aspects of message exchange, including message format, message exchange pattern, and message transport protocol. Based on Web service technologies, SOA has created many new opportunities to meet the challenge of enterprise integration. Specifically, the whole enterprise system is virtualized through a network of services (functionalities). Each service exposes its functionality in terms of a group of interfaces, publicly described and discovered based on Web service standard. Therefore, within a service oriented environment, the enterprise integration problem can be further viewed as a problem of service integration or service composition. Another major challenge faced with enterprise integration is that the integration between systems are currently based on how information is represented (syntax) and 5

23 Chapter 1: Introduction delivered as opposed to what the information means (semantics). As analyzed by Gartner Group, the 95% of difficulties in integrations requires solving semantic issues which surfaces in many aspects, such as: Data formats (type, in the full sense) between applications and systems. Transformation rules: when different data models are used but are related to each other through high and low level descriptions for integration. Transformation rules and functions may be required, but they tend to be different. Transaction rules: different applications participate in different transactions with different rules. Access control rules: when accessing resources, different security policies are imposed. Service level agreement (SLA): when the interactions between applications and services occur, the different SLAs defined with different semantic need to be followed. Hopefully, with the growing complexity of systems and inter-dependency, these issues can be circumvented with rich semantics using Semantic Web service technologies. There are two essential elements in this technology. One is Semantic Web service which is a Web Service whose description is in a language that has welldefined semantics (Sycara et al. 2003). The other is software entity that is able to process this semantic information for some purpose. In a semantic-enhanced service- 6

24 Chapter 1: Introduction oriented environment and with these two essential elements, services can be automatically discovered and composed. A CVE therefore can be automatically formulated. Any manufacturing CVE mass producing variety of products requires several business processes, such as marketing, material/part supplies, product design, planning, quality control and shipping. Semantic Web technology can be exploited in its manufacturing process and workflow to build Semantic Web service network as shown in Figure 1. The core of Semantic Web service network is shared common ontology among participating companies. It consists of set of basic concepts, relation, instance, axiom and functions that provides a common understanding of key terms and concepts of the manufacturing domain. Semantic Web services could be implemented to collaborate with external parties as well as to modularize the system within the enterprise. 7

25 Chapter 1: Introduction Figure 1.1 Semantic Web service network The manufacturing enterprise could outsource some of the manufacturing process like product design to improve agility and quality to meet the customer requirements. The process outsourcing reduces investment requirement and allows the manufacturing enterprise to focus on its core competencies while taking advantage of complementary competencies of participating partners. Thus, Semantic Web service technology provides the company with low-cost, reliable and interoperable infrastructure for integration of systems between business partners. However, as we can see from Figure 1.1, with increasing number of organizations expose their business functions as Web Services and increasing complexity of business processes, the dynamics in real application context make the service 8

26 Chapter 1: Introduction composition much more complicated. It is often desirable to accomplish composition with high degree of serviceability, especially when environment changes or when services previously used becomes unavailable. A composite service for a business goal must be able to address many dynamic changing issues with less or no external interventions, and in this case self-healing capability of a composite service has appeared as an attractive approach. Self-healing refers to a capability of a composite service to maintain its serviceability by healing itself when its component service becomes unavailable or downgraded. A self-healing system must be able to perceive that the system is not operating correctly and make the necessary corrections to restore itself to normal operation without human intervention. It denotes the system has the ability to detect, diagnose and react to system malfunctions to prevent disruptions. To achieve self-healing, a system must have knowledge about itself and its environment, such as current status of its components, available resources and connections with other systems (Horn, 2001). The main motivation of this thesis is the problem of services composition and the self-healing of composite service. The research work has covered the study of the Web Service technology, the Semantic Web technology, service composition and self-healing of composite service. The next section briefly summarizes the objective of the research work followed by section 1.3 for highlighting contribution. A brief introduction of the thesis organization can be found in section 1.4 of this chapter. 9

27 Chapter 1: Introduction 1.2 Research goals The new SOA paradigm has imposed a great challenge to service composition and dynamic self-healing for composite service. The main objectives in this thesis are to extensively explore semantics for facilitating Web service composition and for realizing dynamic self-healing for composite services in a semantic-enhanced serviceoriented manufacturing CVE. To realize the above objectives, we conduct extensively theoretical research and applied research. In the theoretical research, we will compare two representative service composition strategies BPEL and OWL-S; propose a service composition algorithm based on OWL-S and a service selection algorithm based on Genetic Algorithm (GA). A hierarchical service composition framework will be proposed to handle tasks of complex service composition. Within this framework, the description of each Web Service will be enhanced with rule-based modeling of the essential business logic behind the service interface. Finally, a self-healing mechanism will be proposed to dynamically replace the faulty service with suitable alternatives such that the composite service can be performed smoothly. In the applied research, we will first build a semantic-rich service-oriented CVE as a vehicle for further research on service composition and self-healing of composite service based on Web Service standards. Then we will realize service composition in a manufacturing CVE using BPEL and OWL-S respectively. To realize the hierarchical service composition framework, a rule evaluator will be developed to 10

28 Chapter 1: Introduction process the business rules; a service composition controller will be implemented to realize the service selection algorithm based on GA; a semantic-driven service chainer based on OWL-S will be developed to realize the goal-oriented forwardchaining algorithm. In order to achieve dynamic self-healing for composite services, a self-healing capable composite service execution system will be presented where an OWLS2BPEL Mapper will embed the self-healing mechanism into BPEL workflow. 1.3 Contribution We highlight the contributions of the work carried out in this thesis in the following: A semantic rich service-oriented manufacturing CVE has been build where a collection of Web services were developed. They are further annotated with OWL-S upper ontology and domain ontologies to become a collection of Semantic Web services. Within the service-oriented paradigm, two representative service composition strategies BPEL and OWL-S are investigated to realize service composition in a service-oriented manufacturing CVE. The critical analysis of BPEL and OWL- S is conducted in the manufacturing CVE scenario. Five key criteria for evaluating technologies of service composition are identified. Moreover, a semantic-driven services composer based on OWL-S is developed and the goaloriented forward-chaining algorithm is presented. 11

29 Chapter 1: Introduction In order to systematically address semantic web service composition, a business rule enhanced semantic service composition framework is further presented and analyzed. We adopt the divide-and-conquer strategy and propose a hierarchical composition architecture to handle tasks of complex service composition. In this framework, the description of each Web Service is enhanced with rule-based modeling of the essential business logic behind the service interface. A formal notion of service utilities has been provided. Complete processes for calculating the service utilities have also been introduced through processing and evaluating these business rules. A PC manufacturing CVE derived from a practical industrial setting is designed and a prototypeing system is developed to experimentally evaluate the effectiveness of our service composition framework. A self-healing capable composite service execution system is proposed. The execution system takes advantage of the complementary strengths of OWL-S and BPEL in the following ways: (1) a dynamic self-healing mechanism is proposed which can dynamically identify suitable alternatives and replace faulty services such that a composite service can be performed successfully despite of unexpected exceptions; (2) an OWL-S process to BPEL process Mapper is presented which can translate OWL-S process to BPEL process and meanwhile embed the self-healing mechanism into BPEL workflow. Semantic Web service technology plays its part for service matching and selection during the selfhealing process in a sense that Semantic Web services are equipped with rich business rules in a domain-dependent manner. A concrete scenario PC 12

30 Chapter 1: Introduction manufacturing CVE is used to demonstrate the effectiveness of self-healing capable composite service execution system. 1.4 Thesis outline The structure of this thesis is organized as follows: Chapter 2 presents briefly some background information required to understand this thesis. Chapter 3 introduces a background of the research in service composition and selfhealing for composite service. The review starts with the Semantic Web Service matching followed by variety of service composition systems. Finally, the selfhealing for composite service is reviewed to give a background of the current research. Chapter 4 introduces a scenario semantic rich service-oriented manufacturing CVE, based on which our research on service composition and self-healing for composite service conducted. It first presents a traditional manufacturing workflow followed by a service-oriented manufacturing CVE built through service virtualization. A collection of Web services are developed based on the scenario. To promote automatic service discovery, composition, execution and reuse of knowledge, the services are further annotated with OWL-S upper ontology and domain ontologies to become a collection of Semantic Web services. Finally, the framework of automatic execution of OWL-S atomic service has been presented. 13

31 Chapter 1: Introduction Chapter 5 first introduces the service-oriented integration architecture for CVE. In order to achieve dynamic integration in CVE, two different service composition approaches BPEL and OWL-S are utilized to realize business goals in form of service process. Based on two prototypes developed using these two approaches, comparison study has been conducted through the CVE scenario. In order to systematically address semantic web service composition, Chapter 6 presents and analyzes a business rule enhanced semantic service composition framework. We adopt the divide-and-conquer strategy and propose a hierarchical composition architecture to handle tasks of complex service composition. In this framework, the description of each Web Service is enhanced with rule-based modeling of the essential business logic behind the service interface. A formal notion of service utilities has been provided. Complete processes for calculating the service utilities have also been introduced through processing and evaluating these business rules. A PC manufacturing CVE derived from a practical industrial setting is designed and a prototypeing system is developed to experimentally evaluate the effectiveness of our service composition framework. Chapter 7 first introduces a self-healing capable composite service execution system which takes advantage of the complementary strengths of OWL-S and BPEL. A dynamic self-healing mechanism is proposed which can dynamically identify suitable alternatives and replace faulty services such that a composite service can be performed successfully despite of unexpected exceptions. An OWL-S process to 14

32 Chapter 1: Introduction BPEL process Mapper is presented which can translate OWL-S process to BPEL process and meanwhile embed the self-healing mechanism into BPEL workflow. Semantic Web service technology plays its part for service matching and selection during the self-healing process in a sense that Semantic Web services are equipped with rich business rules in a domain-dependent manner. A concrete scenario PC manufacturing CVE is used to demonstrate the effectiveness of self-healing capable composite service execution system. Chapter 8 concludes the work, highlights the contributions, and discusses future works. 15

33 Chapter 2: Preliminaries 2 Preliminaries In this chapter, we provide some background information on Web Services, Semantic Web and Semantic Web service to introduce the basic concepts and relevant technologies. 2.1 Web Services The concept of Web Service refers to as Web-based software applications which expose their well defined and self-described interfaces over the Internet using XMLbased technologies. Web Services are implementation-independent. They use standard Internet technologies for messaging and data exchange, which makes implementation logic of Web Services programming language-independent and platform-independent. More specifically, the World Wide Web Consortium (Haas and Brown, 2003) defines a Web service as follows: A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP (Gudgin et al. 2003) messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. 16

34 Chapter 2: Preliminaries Web services make the interoperability among multiple heterogeneous distributed environments possible through a set of XML-based standards. Services can (1) communicate with Simple Object Access Protocol (SOAP), (2) be described by Web Service Description Language (WSDL), (3) be discovered by Universal Description, Discovery, and Integration (UDDI) service. As those standards forms the basis of service composition, to help understand the service composition problem, we will introduce them one by one in this section SOAP SOAP (Gudgin et al. 2003) is an XML based messaging framework which provides a way to communicate with applications by exchanging messages over internet. It is designed for applications to be accessed through loosely coupled infrastructure with implementation independent technologies. It is fundamentally a stateless, one-way message exchange paradigm. An application sends a SOAP request to a Web service, and the Web service returns a SOAP response. But applications can create more complex interaction patterns by combining such one-way exchanges. SOAP provides a distributed processing model where a SOAP message is delivered from a sender to an ultimate receiver via zero or more SOAP intermediaries. This distributed processing model can support many message exchange patterns including but not limited to one-way messages, request/response interactions, and peer-to-peer conversations. 17

35 Chapter 2: Preliminaries SOAP has three parts: (1) a mandatory SOAP envelope describing what is in a message and how to process it; (2) a set of encoding rules for expressing instances of application-defined data types; (3) a convention for representing remote procedure calls and responses. In addition, its binding mechanism makes messages transmitted over different network protocols such as HTTP, , etc. With an attachment mechanism, applications can use SOAP messages to send a large quantity of binary data (Gudgin et al. 2003) WSDL Whereas SOAP is the communication protocol of Web services, WSDL (Chinnici et al. 2007) is the language to describe the mechanics of interacting with a particular Web service. WSDL comprises two parts: a reusable abstract part and a concrete part. The abstract part of WSDL describes messages being exchanged and port types which are collections of operations the service exposes. An operation is a sequence of input and output messages. An operation associates a Message Exchange Pattern (MEP) with the message types that will be exchanged during execution. The message types are defined using a schema language such as (but not limited to) XML Schema. It provides a simple way for service providers to describe the basic format of requests to their systems regardless of the underlying run-time implementation. The concrete part of WSDL describes bindings and ports which provides information about communication protocol and message format for a particular port type and the location of the service. There may be multiple bindings for a given port type. 18

36 Chapter 2: Preliminaries UDDI UDDI (Clement et al. 2004) is an emerging standard registry and lookup system for Web Services. UDDI not only allows businesses to advertise their Web Services by publishing their descriptions on a global registry, but also allows a service consumer to easily, dynamically locate Web Services over the Internet. UDDI plays an important role of a service registry for developers to query a Web services repository and ascertain those required services during design and development. Moreover, UDDI can be queried at runtime to find an implementation of a service which then can be accessed dynamically. Three types of information can be registered: White Pages that list contact information about the company that developed the Web service; Yellow Pages that organize Web services by such categories as geography and industry code; and Green Pages that hold WSDL descriptions. UDDI supports the association of an unbounded set of properties to the description of Web Services via a construct called TModel. For example, a service may specify its category using an arbitrary classification system though their meaning is not codified, 19

37 Chapter 2: Preliminaries therefore there may be two different TModels with the same meaning, but this similarity cannot be recognized. 2.2 Semantic Web In 2001, Tim Berners-Lee et al. proposed the Semantic Web where they portrait a scenario with Semantic Web and intelligent software agent. In this scenario, Semantic Web agent is able to lookup several list of matching providers with trusted service rating, validate the restriction set by the user, make an appointment in line with user s busy schedules and also make suggestion to alter schedules to meet the restriction set by the user. This scenario mentioned above cannot be achieved in the World Wide Web of today. Although the current Web provides large amount of information mostly in forms of human understandable HTML pages, it does not provide enough underlying structure information of the data to support advanced computer processing of content. The Semantic Web (Berners-Lee et al. 2001) is an extension of the current Web in which information is given well-defined meaning, better enabling computers and people to work in cooperation. It provides a common framework that allows data to be shared and reused across application, enterprise, and community boundaries. The Semantic Web provides computers with structured collection of information and set of inference rules that can be used to conduct automated reasoning. It is a collaborative effort led by W3C with participation from a large number of researchers and industrial partners. 20

38 Chapter 2: Preliminaries Ontology The Semantic Web requires explicit semantics that support machine processing of information. The concept of ontologies enables the description of explicit semantics. The realization of the Semantic Web depends on the ability to semantically markup Web resources by ontologies. A widely accepted definition of ontologies was established by Thomas Gruber: An ontology is an explicit and formal specification of a conceptualization of a domain of interest (Gruber, 1993). It is a specification of formally described, machine-readable collection of concepts and their relationships (Heflin, 2004). The main purpose of building ontology is to enable knowledge communication and management easier. By marking up Web content, its properties, and its relations, Semantic Web is realized in an ontology language with a well-defined semantic. W3C has published a stack of ontology languages to be used on Semantic Web, as illustrated in Figure 2.1. Resource Description Framework (RDF) (Klyne and Carroll, 2004) and RDF Schema (Brickley and Guha, 2004) constitute the foundation layer of the Semantic Web stack. RDF provides a framework for describing resources in a simple triple-based assertional language. Triples are statements that contain a subject, a predicate and an object. The subject of an RDF statement is an RDF resource being described. The 21

39 Chapter 2: Preliminaries predicate is a specific property. The object value of the property is either a resource or a literal. RDF Schema (RDFS) is an extension to RDF with additional semantic features, which includes providing mechanisms for defining a class concept, restricting property use, defining specialization relationship between classes and properties, etc. Built on top of RDF and RDFS, the Web Ontology Language (OWL) (McGuinness and Harmelen 2004) is the most expressive standardized Semantic Web language. It has evolved from the DARPA Agent Markup Language (DAML) and Ontology Inference Layer (OIL) languages into the W3C recommendation. DAML was developed as a result of a Defense Advanced Research Projects Agency (DARPA) program from the United States Department of Defense. In parallel with the DARPA program, European Union (EU) researchers were developing the OIL. In March 2001, DAML is merged with OIL resulting in the DAML+OIL language (Horrocks et al. 2001), a predecessor to OWL. In February 2004, the W3C adopted OWL as an official recommendation. In OWL, the ontology is represented as a set of classes, properties, and constrains on the way those classes and properties can be employed. OWL extends RDFS to allow for the expression of complex relationships between different RDFS classes and of more precise constraints on specific classes and properties (McGuinness and Harmelen, 2004). Being benefit from many years of research in description logic, OWL adds more constructs to create new class descriptions as logical combinations 22

40 Chapter 2: Preliminaries (intersections, unions, or complements) of other classes, define cardinality restrictions on properties, provide richer typing of properties (data & object) and so on (Herman and Hendler, 2004). The OWL ontology usually includes following elements (Bechhofer et al. 2004): Classes concepts of the domain, Object properties relations between classes, Datatype properties attributes of classes, Restrictions constrains on properties, Individuals instances of classes and properties. OWL has three different species: OWL-Lite, OWL-DL and OWL-Full, with increasing expressiveness. OWL-Lite provides the simplest constructs that allow for classification hierarchies and simple constraint features. The OWL-DL provides more complex constructs for description logic that allows automatic reasoning. The most complex OWL-Full includes a freedom of RDF. In contrast with OWL-Full, OWL- Lite and OWL-DL places certain restrictions on RDF and RDFS so as to be compatible with the traditional semantics of description logics. The three species are meant for user groups with different requirements of expressiveness and decidability. 23

41 Chapter 2: Preliminaries Figure 2.1 Architecture of the Semantic Web [Taken from (Berners-Lee, 2003)] Rule Although ontologies play the primary role in the Semantic Web, rules are a key element of the Semantic Web vision as well, allowing integration, derivation, and transformation of data from multiple sources in a distributed, transparent, and scalable manner. In service oriented environments, rules can automate the processes execution, the access to services, or the enforcement and composition of policies governing the delivery of information. In addition to its flexibility and manageability, its declarative nature makes it a programmatic and knowledge representation device in a distributed and Web-based environment. In order to share rules and process them with different software, several important standardizations have been motivated such as RuleML (Rule Markup Language), SWRL (Semantic Web Rule Language) and so on. 24

42 Chapter 2: Preliminaries RuleML (The Rule Markup Initiative) is developed by the Rule Markup Initiative for publishing and sharing rule bases on the World Wide Web. It aims to standardize inference rules so as to meet the various needs of rules such as business rules and rules for intelligent agents, Web services, etc (Golbreich 2004). Built upon XML, RDF, XSLT, and OWL, RuleML encompass a hierarchy of rules, including reaction rules (event-condition-action rules), transformation rules (functional-equational rules), derivation rules (implicational-inference rules), also specialized to facts ('premiseless' derivation rules) and queries ('conclusionless' derivation rules), as well as integrityconstraints (consistency-maintenance rules). The Datalog (constructor-function-free) sublanguage of Horn logic is the foundation for the kernel of RuleML (Boley et al. 2005). SWRL (Horrocks et al. 2004) is more recently introduced as a way to integrate rules with OWL ontology. It is based on the combination of OWL DL and OWL Lite sublanguages of OWL with Unary/Binary Datalog sublanguages of the RuleML. Many of the constructs of RuleML are incorporated into SWRL. As it is constrained to be used in the context of OWL, it inherits important semantic characteristics that make automated reasoning more tractable. Its Horn-like rules expressed in terms of OWL concepts can infer new knowledge from existing OWL knowledge bases. Furthermore, SWRL facilitates rule system interoperability on the Semantic Web (O connor et al. 2005) as SWRL does not restrict the way the reasoning performed with SWRL rules so that a variety of rule engines can be used. 25

43 Chapter 2: Preliminaries 2.3 Semantic Web Services Web Services have transformed the World Wide Web from collection of information into distributed collection of dynamic computing systems. Although current Web Service technologies provide interoperability between many different platforms through common industry standards, they operate at a syntactic level and still need human interaction to some extent. For example, a programmer has to manually search for suitable Web Services and combine them in a useful way to fulfill a complex task. With a large number of Web Services available on the internet, users without enough knowledge about the partner services may spend much time searching for the appropriate services, and they are likely to miss some highly suitable services. In order to bring the Web to its full potential and automate tasks, such as Web Service discovery, composition and execution, semantic description of Web services is required (Fensel and Bussler, 2003) to enable seamless interoperation between them while keep human intervention to a minimum. In this section, we give an overview of existing approaches (WSDL-S, WSMO, OWL-S, SAWSDL) to Semantic Web Services WSDL-S A lightweight extension to the WSDL specification WSDL-S (Akkiraju et al. 2005) is being jointly proposed by the LSDIS lab and IBM research. It proposes a mechanism for annotating Web services with semantics. In WSDL-S, the expressivity of WSDL is augmented with semantics by employing ontological concepts while 26

44 Chapter 2: Preliminaries being agnostic to the semantic representation language. The mechanism itself is simple and utilizes the extensibility elements of WSDL for annotation purpose. In essence, WSDL-S provides URI reference mechanism via extensibility elements to the interface, operation and message constructs, and these references point to the semantic annotations defined in the externalized domain models for services WSMO The Web Services Modelling Ontology (WSMO) (Roman et al. 2004) is inspired by the conceptual work done in the definition of Web Service Modeling Framework (WSMF). It is a conceptual model for the description of semantic web services together with a family of underlying formal languages (WSML) and an execution environment (WSMX). WSMO attempts to integrate the basic Web design principles defined for the Semantic Web with design principles for distributed, service-oriented computing of the Web. WSMO is also ontology-based in that all resource descriptions and all data interchanged during service usage are based on ontologies, aiming to solving the integration problem. The conceptual model of WSMO contains four top elements as shown in Figure 2.2. The Goals provide means to specify the requester-side objective when consulting a Web service, describing at a high-level concrete task to be achieved. Ontologies provide the formally specified terminology of the information that describes various aspects related to Semantic Web services and used by all other components. The Web services provide semantic description of services including their functional and non- 27

45 Chapter 2: Preliminaries functional properties, as well as other aspects relevant for inter-operation. The Mediators are connectors between components that resolve heterogeneity problem in order to enable interoperation between heterogeneous parties. Figure 2.2 The main elements of WSMF WSMO Studio (WSMO, 2008) is an open source Semantic Web Service and Semantic Business Process modelling environment for the WSMO. It is a set of Eclipse plug-ins that can be further extended by 3rd parties. It features an SAWSDL editor for adding semantic annotations to WSDL documents OWL-S OWL-S (Web Ontology Language for Services) (OWL-SCoalition 2004) provides a collection of OWL upper ontologies to describe Web Services. It focuses on capabilities, functional properties, and other non-functional properties (such as QoS). An OWL-S description of a Web service is composed of three parts: the service profile, process model, and grounding. The ServiceProfile describes what the service does by specifying the input and output types, preconditions and results, named IOPR. 28

46 Chapter 2: Preliminaries The ProcessModel describes how the service works; each service is either an AtomicProcess that is executed directly or a CompositeProcess that is a combination of subprocesses (i.e., a composition). The Grounding contains the details of how an agent can access a service by specifying a communications protocol, parameters to be used in the protocol, and the serialization techniques to be employed for the communication. The main differences between WSMO and OWL-S are as follows (Lara et al. 2005): WSMO describe the service request in terms of goals while OWL-S uses service profile to characterize the service. WSMO explicitly separates the goals and service capabilities while OWL-S use a single modeling element (service profile) for describing both the service offered by the provider and the service desired by the requester. WSMO allows a set of core non-functional properties to be accessible to all modeling elements, while only service profile can define the non-functional properties in OWL-S. WSMO encourage the reuse of widely accepted terminologies such as Dublin Core Metadata Elements Set, while OWL-S does not explicitly consider such commonly used vocabularies. In order to handle the heterogeneity problems inherent to a distributed environment, different kinds of mediators are used to link together the core 29

47 Chapter 2: Preliminaries WSMO elements. OWL-S treats the heterogeneity problem as an architectural issue i.e. mediators are not an element of the ontology but are part of the underlying Web Service infrastructure SAWSDL Based on earlier work on WSDL-S, the Semantic Annotations for WSDL and XML Schema (SASWDL) defines how to add semantic annotations to various parts of a WSDL document such as input and output message structures, interfaces and operations. Specifically, it defines a set of extension attributes for the WSDL and XML Schema definition language that allows description of additional semantics of WSDL components (SAWSDL, 2007). The WSDL describes the Web Service on a syntactic level - specifies what message looks like rather than what they mean. SAWSDL is a simple extension layer on top of WSDL that lets WSDL components to specify their semantics using extension attributes. It has two basic types of annotations, the model reference and the schema mapping. The model reference annotation, the same as the WSDL-S model reference, is used to point to semantic concepts. The schema mapping annotations specifies data transformations between message structures and associated semantic model. SAWSDL alone isn t an actual framework for modeling Semantic Web Services; it needs concrete service ontology. However, it is agnostic to semantic representation languages and does not specify a language for representing the semantic models or ontologies. And it assumes that semantic concepts can be identified via URIs 30

48 Chapter 2: Preliminaries (Kopecky et al. 2007). For instance, a Semantic Web Service (SWS) framework can either use the RDF, or other ontology language with SAWSDL to annotate Web services. This is because SAWSDL provides mechanism by which concepts from the semantic models that are defined either within or outside the WSDL document can be referenced from within WSDL components as annotations. There exist several tools and APIs that support SAWSDL specifications. SAWSDL4J (SAWSDL4J Home, 2007) is one of Java implementations allowing the development of SAWSDL based applications. It extends the WSDL4J API for WSDL1.1. SAWSDL efforts are based on the WSDL-S approach. Radiant (Radiant) is an eclipse plug-in that provides a UI for annotating existing WSDL documents into WSDL-S or SAWSDL via an OWL Ontology (Gomadam et al. 2005). 31

49 Chapter 3: Related Work 3 Related Work The evolution of the Web triggered XML-related standards pave the way for Web service prevalence. With the prevalence of Web service from early 2000, service composition gained a considerable number of research efforts (Papazoglou et al. 2007; Yu et al. 2008; Milanovic & Malek, 2004; Ardagna & Pernici, 2007; Charfi & Mezini, 2005) in both academia and industry as composite services provide much higher value than individual services (Martin and Domingue, 2007). However, with dramatic growth of the number of the component services involved in a composite service during the recent years, a composite service for a business goal must be able to address many dynamic changing issues such as its component service becomes unavailable or downgraded. In this case, self-healing capability of a composite service has appeared as an attractive approach. In this chapter, a background of the research in service composition and self-healing for composite service is presented. The review starts with the Semantic Web Service matching as it is closely related to the service composition; then variety of service composition systems is introduced. Finally, the self-healing for composite service is reviewed to give a background of the current research. 3.1 Web service composition Normally, a typical Semantic Web Service application involves three steps: discovering the available services on the Web including matching the capabilities of 32

50 Chapter 3: Related Work the services with user s requirements; composing multiple services to fulfill ultimate objective; and finally, executing the generated composition automatically. Over the past few years, service composition has attracted tremendous research attention both in industry and in academia. For example, Driven by industrial applications, BPEL (Alves et al. 2006) provides a language for the formal specification of business processes and business interaction protocols. Currently the technology is quickly gaining its popularity in real-life projects. In academia, inspired by the booming research development in Semantic Web technology and aimed at fully automating service discovery and composition, OWL-S has been developed in the past few years as an ontology language for machine understandable description of Web services (OWL-S Coalition, 2004). In addition to composition languages, a wealth of service composition systems has been published recently in the literature. In general, there are four different dimensions to characterize a composition system: (1) the degree of user involvement in specifying a composition, (2) the availability of templates to guide the composition, (3) the adaptability of a composition, and (4) the degree of user involvement in the adaptation of the composition (Cardoso and Sheth, 2003). A composer can be defined fully by a user through explicitly specifying the control and data-flow information. At another extreme, a composed service execution sequence can be obtained automatically without any human intervention. Between the two extremes, a composer might work under the partial help from users or based on pre-defined 33

51 Chapter 3: Related Work service composition templates. Moreover, in a dynamic environment, the composed service itself can be adapted due to the change of Quality of Services (QoS) requirements at runtime. In general, various hybrid methods such as semi-automatic compositions and semi-automatic adaptations are technically possible. Based on literature review, composition approaches can be classified into five categories: (1) semi-automatic service composition, (2) Artificial Intelligence (AI) based service composition, (3) semantic-based service composition, and (4) QoS based service composition and others. Since matching capabilities of services is very closely related to the composition, we will introduce Semantic Web Services matching first followed by representative systems and technologies of each category Semantic Web service matching Semantic matching is one of the keys to success of effectively retrieving relevant services in the Semantic Web Services composition. A few matchmakers have been developed in recent years such as the DAML-S matchmaker (Sycara et al. 2003), RACER (Li and Horrock, 2003), SDS (Mandell and McIlraith, 2003), LARKS (Sycara et al. 2002), OWLS-MX (Klusch et al. 2006), etc. Most of approaches define the formal semantics of services in some decidable description logic based ontology languages such as OWL. In this way, description logic reasoning can be applied to automatically determine services that semantically match with a given service request 34

52 Chapter 3: Related Work based on the concept subsumption relations in the corresponding ontology (Klusch et al. 2006). One representation of such logic-based approaches is the DAML-S matchmaker (Paolucci et al. 2002) which was developed by the Intelligent Software Agents Group at Carnegie-Mellon University. The solution is based on DAML-S for service description. The service capabilities are presented in DAML-S Profile, which is described in terms of inputs, outputs, preconditions and effects (IOPE). It is intended to specify what the service requires, what result it delivers and what the state transformation produced. The task of the matchmaker is to select the advertisements that match a given request according to their similarity of the service capabilities. The matching algorithm consists of the match of outputs of the request (outreq) against outputs of the advertisement (outadv); and match of inputs of the advertisement (inadv) against inputs of the request (inreq). The basic idea used is: semantic subsumption relationship between the concepts associated with each input or output decides the degree of match between two outputs or two inputs. The degree of match includes: exact match, plugin match and subsumes match. Li and Horrocks (Li and Horrock, 2003) uses a modified version of the DAML-S Profile in matchmaker process. In addition to the degrees of matching in DAML-S matchmaker mentioned above, they extend the match level by adding intersection match which means only part of request are satisfied by the advertisement. A 35

53 Chapter 3: Related Work Description Logic reasoner RACER is used to compute the subsumption relations between advertisements and requests. Advertisements and requests are described in Description Logic notations. Sycara et al. have defined a language called LARKS (Language for Advertisement and Request for Knowledge Sharing) (Sycara et al. 2002) for agent advertisements and requests. They developed a LARKS matchmaker which performs both syntactic and semantic matching. Five different filters are identified to reduce the number of matching candidates. They are: context matching, profile comparison, similarity matching, signature matching and constraint matching. Different combinations of these filters result in different degrees of partial matching. The filters provide a mechanism to balance between quality of matching and required matching time. In order to use application domain knowledge in any advertisement or request to describe the meaning in a LARKS specification, LARKS provides a specific concept language ITL to describe local ontologies. Based on LARKS, Klusch presents the first hybrid OWL-S service matchmaker called OWLSMX, which uses both logic based semantic reasoning and information retrieval based approximate matching (Klusch et al. 2006). Five different filters in OWLS-MX are provided: exact, plug in, subsumes, subsumed-by and nearestneighbor. The first three are logic based only whereas the last two are hybrid due to the required additional computation of syntactic similarity values. The OWLS-MX takes any OWL-S service as a query and computes the degree of semantic matching 36

54 Chapter 3: Related Work for a given pair of service advertisement and request by applying these five filters. Finally, it returns an ordered set of relevant services that match the query. Each relevant service is annotated with its degree of matching and syntactic similarity value. User can specify the desired degree and syntactic similarity threshold. The majority of above mentioned matchmakers based on OWL-S ontologies use profile for service signature (I/O) matching (Kawamura et al. 2003). Alternative approaches include service process-model matching (Bernstein and Klein, 2004), recursive tree matching (Bansal and Vidal, 2003), P2P discovery (Banaei-Kashani et al. 2004), automated selection of WSMO services (Keller et al. 2005) and METEOR- S for WSDL-S services (Verma et al. 2005). In order to improve service retrieval precision and make people easy to express semantics, Bernstein and Klein (2004) propose a process-based service model to capture service behavior. Using this process model, service processes can be decomposed into subprocesses and annotated with attributes and exceptions as well as resources they use, consume, or create. A Process Query Language (PQL) is designed for retrieving process model. A pattern-matching algorithm is proposed to discover user required services Semi-automatic service composition In (Sirin et al. 2003), Sirin et. al. proposed a semi-automatic user-driven Web Service composition system. Different from our research, composite services in their system will be established through a chaining procedure driven primarily by human decisions. 37

55 Chapter 3: Related Work Essentially, services selected to fuel a business workflow are direct outcomes of nonfunctional constraints specified by users. At each composition step, an interactive user interface will list a group of Input/Output compatible services for users to select and filter. After making certain selection decisions, another group of compatible services will be further presented to the user until the whole business process is formed. In comparison to their approach, our research leads to an automatic technique for service composition with very limited human intervention. High-level automation is achievable in our research thanks to the ability of modeling and processing the underlying business logic of each Web service in the form of service preconditions and results AI based service composition In an attempt to reduce human involvement, AI planning techniques, which have been extensively utilized in AI systems such as SHOP2 (Sirin et al. 2004), have been exploited to enable automatic service composition. For example, in (Sirin et al. 2004), an algorithm is proposed to transform service composition tasks to planning problems which are directly solvable through SHOP2. In order to build up a rigorous transformation procedure, assumptions and compromises are necessary (Sirin et al. 2004), leading to undesirable loss of information in service descriptions. Unfortunately, such loss of information will significantly affect the quality of composition result. Without excluding the potential of using AI planning tools as suggested in (Sirin et al. 2004), our research emphasizes the expressiveness of service 38

56 Chapter 3: Related Work descriptions, especially the modeling and processing of business logic behind standard Web service interface and its utility to a business process in general. In addition to AI planning, rule-based composition systems such as SWORD (Ponnekanti and Fox, 2002) can automatically verify whether a desirable composite service can be built from existing services. Different from our research, SWORD uses Entity-Relation (ER) model to describe inputs and outputs of Web Services. Given inputs and outputs of a service, a Horn rule is defined with service inputs as antecedent and services outputs as consequent. When the antecedent is satisfied, the consequent will take effect. A concrete business process will be created using a rulebased expert system upon providing the initial inputs and expected final outputs of the composite service to SWORD. As the composition process considers only the inputs and outputs of services, it is highly likely that the composite services thus formed will fail to meet the real business objectives of CVE Semantic-based service composition It is argued that the notion of composeability significantly facilitates the reuse of services and dynamic composition (Medjahed et al. 2003; Yang et al. 2006). Inspired by the concept of composeability, a service composition framework has been proposed in (Medjahed et al. 2003), which is based on WSDL service descriptions with extended semantic capability. To guide the service composition process, a composability model is proposed in (Medjahed et al. 2003) with two sets of composability rules to compare both syntactic and semantic features of Web Services. 39

57 Chapter 3: Related Work Syntactic rules include rules for operation modes and the binding protocols of interacting services. Semantic rules comprise (1) message composability, (2) operation semantics composability, (3) qualitative composability, and (4) composition soundness. In order to check the composition soundness, they introduce the concept of composition template to check whether the generated composite service provides an added value. Our composition framework can be considered as a complement (or extension) to this framework since the composeability of a service will be evaluated according to not only the syntactic compatibility but also the underlying business logic (Yang et al. 2006). As we believe, business logic will play a decisive role in determining the ultimate composeability of a service and their existence may significantly alter the landscape of composeable services for any business process. Keita (Fujii and Suda 2005) proposed a semantic-based service composition architecture which allows a user to request a service using natural language. The semantics of the requested service expressed by a user in an intuitive form can be converted into a machine-understandable format (e.g. semantic graph) with the help of natural language analysis tools. The proposed architecture contains three major models to support semantic representation of components, component discovery, workflow formation and execution. They are Component Service Model with Semantic (CoSMoS), Component Runtime Environment (CoRE) and Semantic Graph-Based Service Composition (SeGSeC). 40

58 Chapter 3: Related Work CoSMoS describes a service as a semantic graph which consists of nodes and labeled links. Nodes represent operations, inputs, outputs and properties of a service, as well as their data types and concept. Labeled links represent the relationships among the nodes. CoSMoS models the semantics of a service using concepts which is similar to the Semantic Web Service standards such as OWL-S and WSMO. The differences between CoSMoS and other Semantic Web Service standards are three aspects: (1) in addition to model the input, output and property of a service, CoSMoS annotates the concept of an operation of a service; (2) CoSMoS distinguishes the concept and the data type of an input, output and property; (3) due to the difficulty to obtain a logic formula from a natural language, CoSMoS models the semantics of an operation as a predict node with a direct link connected to an operation node. Different from this approach, in our research, the semantics of a business operation will be modeled by the precondition and result of the respective Web service in the form of business rules to support dynamic service composition and self-healing for composite service QoS aware service composition Despite of functional similarities, existing Web services usually offer varied Quality of Service (QoS). In order to determine the suitability of a Web service for a business process, QoS information can be explored. For example, Zeng (2004) presented a middleware platform, named AgFlow, that supports quality driven Web service compositions. Without infringing user's preferences and other global constraints, AgFlow intends to select Web services in such a way that the QoS of the resulting 41

59 Chapter 3: Related Work composite service can be maximized. To achieve this goal, a service quality model is utilized in their research to capture non-functional properties of Web services such as availability and reputation. Ontologies have also been defined for service descriptions and the service quality model. Two QoS-driven service selection approaches are designed and compared, namely, local optimization and global planning. In the local optimization approach, service selection is performed for each individual task in a composite service without considering its possible side-effects to global QoS. On the other hand, the global planning approach considers both the QoS preferences and constrains of a composite service. Integer programming technique is used to find the optimal composite service. In addition to (Zeng et al. 2004), Gu and Nahrstedt has recently proposed another interesting service composition framework, which explicitly utilized the stochastic QoS information to facilitate the service selection decision (Gu and Nahrstedt, 2006). It provides multi-constrained statistical QoS assurances for the composed service through bounded composition probing (BCP) scheme. The main idea of BCP scheme is to execute a hop-by-hop distributed composition protocol to select the best service composition through the following three steps. It first discovers available services that match the users' requirements. Second, it checks statistical QoS condition, resource availability and service dependency relations to select qualified services. Third, it collects statistical QoS and resource state information from the selected candidate services. Based on probing results, users QoS requirements and global load balancing objective function, the best composite service is selected finally. 42

60 Chapter 3: Related Work Different from QoS based service composition, in a CVE, we believe it is more important to understand the actual utility of a Web service to a business process. Utility-driven service selection is therefore much more crucial to ensure that the business targets of the CVE can be eventually realized via the business processes it supports, as exemplified in chapter Others Composition templates are adopted in some research works in an attempt to reduce the problem complexity. For example, Benatallah (Benatallah et al. 2002) proposed the design and implementation of SELF-SERV (composing web accessible information & business services): a framework for dynamic and peer-to-peer provisioning of Web services. This system provides tools for specifying composite services through state charts. The resulting composite services are executed by replacing the roles in the chart with selected individual services. 3.2 Self-healing for composite service Autonomic computing systems In recent years, the increasing software complexity becomes the most important challenge facing the IT industry (Horn, 2001). A large number of skilled IT staff are required daily to install, configure and maintain the applications whose complexity demands tens of millions of lines of code. The Internet which connects heterogeneous computer systems adds a new level of complexity. When failures happen in such a 43

61 Chapter 3: Related Work system, overworked IT staffs often can t determine the root cause of failures quick enough to avoid mission-critical problems. Management of such complexity has been far more beyond the human's capability. As a consequence, the ultimate and possibly only solution is autonomic computing, which is a new idea introduced by IBM's senior vice president of research, Paul Horn. Inspired by the autonomic nervous system of the human body (Horn, 2001), an autonomic computing system would manage the functioning of computer applications and systems by themselves with limited direct human intervention in case of failure, malicious attack, etc. IBM defines eight key characteristics for an autonomic computing system (Horn, 2001; Kephart and Chess, 2003): 1) it needs comprehensive and specific knowledge about all its components; 2) it must have the ability to self-configure to best handle varying and possibly unpredictable conditions; 3) it must constantly monitor its components for self-optimization; 4) it must perform self-healing and able to find alternate ways to recover from fails; 5) it must perform self-protection; 6) it must have environment-aware ability and act accordingly; 7) it must implement open standards; 8) and it must anticipate demand without user intervention. Selfmanagement is the essence of an autonomic computing system which includes following properties: self-configuration, self-optimization, self-healing and selfprotection (Kephart and Chess, 2003), together with self-awareness, self-adaptive and self-organizing (Tosi, 2004). 44

62 Chapter 3: Related Work Self-healing system Although most of the autonomic computing concepts are still premature, several leading IT vendors such as IBM, HP, SUN and Microsoft are carrying out research on autonomic systems. Self-healing concepts are typically part of them. Some researchers view the self-healing systems as a subset of traditional fault tolerant computing systems. However, many fault tolerant systems rely on spare components to take the place of failed components. Most of their operations or hardware needs to be mirrored or duplicated which is a very expensive way. Very often, human intervention is required to resolve the problem. In contrast, self-healing systems concern more about healing itself; they focus on how to recover from unhealthy state to healthy state. The healing or recover process is the essential aspect of self-healing systems. Self-healing denotes the system has the ability to detect, diagnose and react to system malfunctions to prevent disruptions without human intervention. A selfhealing system must be able to perceive that the system is not operating correctly and make the necessary corrections to restore itself to normal operation. To achieve selfhealing, a system must have knowledge about itself and its environment, such as current status of its components, available resources and connections with other systems (Horn, 2001). There are some applications exploit self-healing techniques to enhance system capability and reliability. For example, Nitix is the World's first self-healing Server Operating System which is able to detect, diagnose and repair problems. Nitix- 45

63 Chapter 3: Related Work powered servers also have the ability to detect and evade malicious external attacks. If a foreign program should attempt to modify the Nitix operating system, Nitix will automatically write-over that attempted change (Nitix). Self-healing networks are designed to be robust even in environments where individual links are unreliable, making them ideal for dealing with unexpected circumstances, such as public safety systems (Yang et al. 2006). Self-healing strategies is also implemented in Clustered system for managing resource discovery, allocation and dynamic reconfiguration at run-time, and mostly without service interruption (Corsava and Getov, 2002). Service discovery systems enable distributed software components to discover each other, and to determine if discovered components meet specific requirements. Its discovery protocols rely on several self-healing strategies to provide consistent views of distributed components under varying network conditions (Dabrowski and Mills, 2002). In order to build an intelligent, adaptive protection system, a self-healing strategy is also adopted in an agent-based power system (Su et al. 2006). In order to give researchers a common basis for defining the scope of self-healing systems, Philip Koopman proposes taxonomy for describing the problem space for self-healing systems. The taxonomy includes four general categories: fault model, system response, system completeness and design context (Koopman, 2003). Fault model denotes what type of failure could occur, be detected and recovered. It has five typical characteristics including fault duration, fault manifestation, fault source, granularity and fault profile expectations. System response to a fault includes fault detection, degradation, fault response, fault recovery, time constants and assurance. 46

64 Chapter 3: Related Work System completeness deals with architectural completeness, designer knowledge, system self-knowledge and evolution. Design context of the systems includes abstraction level, component homogeneity, user involvement in healing, system linearity and scope. Ghosh (2007) presents a literature review in the field of self-healing systems and attempts a classification based on similarities or relationship. He believes the key self-healing process includes maintenance of the system health, detection of system failure and system recovery process (Ghosh et al. 2007). Different strategies have been exploited to check for faults periodically to monitor system health including maintaining redundancy of components, probing into the system and assessing the state of the system, analyzing performance log, etc. Research on failure detection can be categorized as dealing with missing components, system monitoring models and identification of foreign elements. The recovery policies in the healing process consist of redundancy techniques like producing replicating components, applying various repair strategies, or employing Byzantine agreement and voting, etc. Variety of techniques has been exploited in a self-healing system recently. Montani and Anglano (2008) present a Case-Based Reasoning approach for achieving selfhealing in service delivery software system. To realize self-healing, the specific knowledge of previously experienced situations, called cases is maintained. The system diagnoses service failure by retrieving past cases similar to the current one and makes remediation by reusing past successful solutions after revising them, if 47

65 Chapter 3: Related Work necessary. The current case can then save into domain knowledge base or case base. In (Arshad et al. 2004), an AI planning-based approach is proposed to automate failure recovery in distributed component-based systems. When a failure is detected, the system captures the state after failure and defines an acceptable recovered state as a goal. Finally, an AI planner is utilized to take the system from a failed state to a working (goal) state. Sterrit (2004) presents an approach to identify faults based on event correlation in autonomic networks. During monitoring phase, various alarm events triggered by different system component are collected. In order to determine the problems occurred, alarm events are correlated to interpreter events involved Self-healing in SOA As systems increase in complexity, self-healing systems are attracting a number of researcher's attention. However, only a few research efforts focus on self-healing in SOA have been reported. Web Services - DIAgnosability, MONitoring and Diagnosis (WS-DIAMOND) (Ws-Diamond, 2005) is a research project funded by the EU commission under the FET Open Framework. It has two main goals: (1) to develop a framework for self-healing Web Services; (2) to devise guidelines for designing services in such a way that they can be easily diagnosed and recovered during their execution. In order to achieve these goals, they carried on research in different areas such as Semantic Web languages for describing service properties, service composition techniques for describing service interaction as well as model-based reasoning and diagnosis. 48

66 Chapter 3: Related Work Within WS-DIAMOND, a runtime platform for supporting self-healing service execution is designed and prototyped. This platform is composed of a self-healing layer, a diagnoser and a repair planner. In the self-healing layer, a self-healing plug-in for BPEL engine (SH-BPEL) (Modafferi et al. 2006) is presented to enhance the ability of a standard engine to provide process-based recovery actions. It provides the capability of associating a diagnostic service to each service and a supervisor to the composite service. The local diagnoser is invoked by the service raised an exception. It computes a local explanation and passes it to the supervisor to integrate it in the global explanation. This approach is different from our research in the following aspects: (1) it uses API from activebpel engine (ActiveBPEL3, 2004) and therefore it is an implementation dependent solution; (2) its recovery mechanism is annotated in the BPEL service flow which can not be executed directly by any BPEL engine; while the output of our Selfhealing Composite Service Generator is a standard BPEL process; (3) Semantic Web service discovery technology is exploited in our self-healing process; (4) our final service selection is based on rule evaluation results. Kunal and Amit propose a framework to elevate automatic computing from infrastructure level to process level to create Autonomic Web Processes (AWPs) (Verma and Sheth, 2005). In their vision, AWPs are defined as Web service based processes that support the autonomic computing properties, such as self-healing, selfconfiguring, self-optimizing and self-aware. These aspects of AWP are studied in a 49

67 Chapter 3: Related Work supply chain process scenario. They believe that the self-healing behavior of AWPs should be controlled by policies defined by users. Two policies are introduced. One is short term policy, e.g. replace the supplier after 5 retries in case of the supplier service failure. The other is long term policy, e.g. try to avoid canceling a preferred supplier order considering a long term business relationship. However, they didn't give technical details about the policy. Our global business rules which determine the alternative plan during the healing process are conceptually similar to the AWPs' policies. 50

68 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE 4 Semantic Rich Service-oriented Manufacturing CVE The goal of this chapter is to build semantic rich service-oriented manufacturing CVE as a vehicle to facilitate systematic studies of service composition and self-healing for composite service. A traditional manufacturing workflow has been introduced first followed by a service-oriented manufacturing CVE. The key step required to utilize Semantic Web technologies for manufacturing domain is virtualization of process and activities in manufacturing domain as Web services using service-oriented architecture. A collection of Web services are developed based on the manufacturing CVE scenario. Each of them is further annotated with one OWL-S upper ontology and three domain ontologies to become a Semantic Web service. The structure of the chapter is as follows: in section 4.1, an overview of a traditional manufacturing enterprise workflow is presented; in section 4.2, a service-oriented manufacturing CVE is built through service virtualization; in section 4.3, semantics is added into the service-oriented manufacturing CVE to promote the interoperability, automation and reuse of knowledge, and the Web services for manufacturing CVE are further augmented to semantic Web services in section 4.4 to facilitate automation of service discovery, selection, composition and invocation. Section 4.5 gives a summary. 51

69 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE 4.1 Traditional manufacturing enterprise In this section, we give an overview of a traditional manufacturing enterprise with focus on workflow and key components at various stage of manufacturing a product Manufacturing overview Manufacturing is the application of tools and a processing medium to transform raw materials into usable goods, which includes all intermediate processes required for the production and integration of a product s components. Production/Manufacturing is a series of interrelated activities of producing usable material (product and service), include planning, design, procurement, production, inventory, marketing, distribution, sales and management (Hitomi, 1996). Figure 4.1 shows a typical order of activities performed by a manufacturing enterprise producing high value goods. The manufacturing enterprise s activities start from the sales and marketing phase where the enterprise will conduct market survey, product feasibility study and sales forecast for new products. In this phase, customer purchase order for products will also be processed and manufacture order for the product will be produced. In the schedule production phase, the manufacturing enterprise will make decisions to produce the master schedule of activities which known as Master Production Schedule (MPS) for the entire manufacturing process according to the manufacture order. The scheduling activities are designed for priority control and capacity control. 52

70 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE Figure 4.1 Manufacturing overview In some scenario, customer may order a new product or a variation of existing product. Thus research and development activities for design of products according to the product specification provided by the customer are required. In the following stage, the production plan will be finalized using master schedule, which involves converting manufacture orders into specific material and capacity requirements. Before the start of product manufacturing, the required raw materials, 53

71 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE components and parts should be purchased. The manufacturing process will produce the components & parts based on the item being manufactured in-house. The purchased or produced components and parts from purchasing process and manufacturing process are temporarily stored into inventory before final assemble of the products. After final assembly, the quality analysis process will ensure the quality of the product being manufactured. The qualified goods are temporarily stored into inventory before being shipped to the customer. The final stage of manufacturing activity is billing for the manufacture and delivery of finished goods to customer Manufacturing workflow A typical manufacturing workflow is depicted in Figure 4.2 which has been simplified by excluding sales & marketing and billing activities. It starts with a customer request in the form of a product order and ends with an invoice and finished goods. Issue Purchase Order will create Product Purchase Order according to customer request. Since customers may have varying requirements based on the product specification, Process Product Purchase Order will consolidate these varying requirements to form aggregated Manufacture Order for production to obtain volume and transport advantages in procuring raw material and actual production of the product. 54

72 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE Figure 4.2 The simplified manufacturing workflow 55

73 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE The Schedule Production process produces a master schedule for manufacturing activities for the entire manufacturing process including design of product, material requirement and capacity requirement planning, purchasing of raw materials, manufacturing, assembly delivery task and activities. The Product Engineering is the process for producing design of new product or variation of existing product. It involves research and development activity for design a product according to the specification provided by the customer. The design effort by the enterprise or outsourced company produces product design specification and may produce production process design specification for the production of such product. The Plan Master Product Schedule is to formalize the production plan which involves converting manufacture orders into specific material and capacity requirements. Plan Material is to determine the quality and timing for the acquisition by purchase or production of necessary dependent components of the end product need to meet the final assembly date and delivery date specified in customer request. Plan Capacity is to determine what human resource and machine equipments are needed to meet the production objectives and make economical usages of the resources. 56

74 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE Based on the confirmed material and capacity, Finite Capacity Schedule will create daily production schedule for Manufacturing Execution System which in turn will produce Job/Lot order for each machine in work center. Purchase Material is the process for acquisition of necessary raw materials for manufacturing of components and parts, or dependent components and parts of the end product needed for final assembly of the product. It will issue a purchase order to material suppliers. Once the required materials or dependent components and parts are received, Material Quality Control will check their quality. The qualified material will be temporarily stored in storage warehouse before final assembly or production of the products. The production operation for components and parts depends on the item being manufactured in-house. The manufacturing process may include processes like casting, molding, forming, cutting, etching, shaping, compacting and assembly to manufacture components and parts. The final assembling process is merely fitting of all the components and parts into main body housing and connecting each component and parts with electrical or physical connection to form final finished goods. The Finished Goods Quality Assurance is to ensure the quality of the product being manufactured. The quality of the product is the measurement of conformity of the product manufactured to the specified standards. 57

75 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE The packaged goods will be temporarily stored in the inventory before shipping to the customer. Product Material Handling is to move the final products onto the vehicles of shipping company. 4.2 Service-oriented manufacturing CVE The ongoing trend of globalization gives rise to an efficient new business paradigm generally known as CVE, where companies increasingly concentrate on their core competencies and outsource all other functions to their partners, formulating a virtual chain of enterprises. A manufacturing CVE is a temporary alliance of manufacturing enterprises to share skills or core competencies and resources in order to better respond to changing product and process requirements in a more collaborative manner. Within this virtual enterprise, companies actively participate in collaboration, and as a result, they are more agile to meet changing market demands. Effective collaboration in manufacturing CVE relies on the computer networks and IT technologies to provide the desirable dynamism and flexibility. A manufacturing CVE needs to be dynamically formulated, configured and executed to respond to the dynamic market (Swamidass, 2002). To achieve above goals, the manufacturing CVE needs a consistent and uniform means of accessing or activating the resources. This can be achieved by exposing the manufacturing process and activities executed by various manufacturing resources as Web service by virtualization of the process. Virtualization enables consistent resource access across multiple heterogeneous platforms (Foster et al. 2002). 58

76 4.2.1 Service Virtualization Chapter 4: Semantic Rich Service-oriented Manufacturing CVE Services provide the highest level of abstraction with well-defined interfaces (input, output and operation which can transform input into output). Once manufacturing process and activities are exposed as Web services, the location of process implementation becomes irrelevant. The manufacturing companies can publish their manufacturing process capabilities for other enterprises to use. This could create a service-oriented manufacturing CVE with each company can specialize on specific process and activities focusing on its expertise and let the partner companies take care of rest of process thus provides an environment of innovation, effective and efficient of resources to produce goods and products as per customer requirement with minimum production cost and high profit margins. The effective collaboration of various manufacturing processes (e.g. scheduling, engineering, material management, manufacturing, inventory, and shipping) is essential to quickly adapt and change its manufacturing process and workflow in responses to changing production technologies, environment and customer requirements. Figure 4.3 shows the service virtualization for manufacturing CVE. With each of the functionality is virtualized through one or multiple Web services, the manufacturing process can take place within an enterprise or at the premises of external partners. For example, the engineering task is embodied by the Product Engineering Web service (E1). Other external partners can directly assess the engineering functionality through invoking E1. It is highly likely that several organizations have contributed to this 59

77 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE service process. As an example, E1 can be provided by a product design firm, which is different from the company that actually manufactures the product. In this manner, the execution of the service process will lead to an effective collaboration among numerous organizations, and a CVE is therefore formed. Figure 4.3 Service virtualization for manufacturing CVE After virtualization, Figure 4.2 also can be seen as a service-oriented manufacturing CVE among which the Issue Purchase Order service (C1) will be invoked first followed by the Process Product Purchase Order service (C2), as the two services are connected with a directed edge. In this CVE, we find the following processes listed in Table 4.1. Each of these processes could be implemented as a Web service and described using WSDL. 60

78 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE Table 4.1 Processes in Service-oriented manufacturing CVE Process Input Output Issue Purchase Order Customer Request Product Purchase Order Process Product Purchase Order Product Purchase Order Manufacture Order Material Request Schedule Production Manufacture Order Engineering Change Request Product Specification Schedule Purchase Material Material Request Material Purchase Order Supplier Material Management Material Purchase Order Material Delivery Order Receive Material Material Delivery Order Received Material Material Quality Control Received Material Verified Material Material Inventory Control Verified Material Stored Material Product Engineering Plan Master Product Schedule Engineering Change Request Product Specification Schedule Design Specification Design Specification Required Material Stock Required Labor Machine Plan Material Required Material Stock Confirmed Material Plan Capacity Required Labor Machine Confirmed Capacity Finite Capacity Schedule Confirmed Material Confirmed Capacity Daily Schedule Manufacture Execution System Daily Schedule Stored Material Job/Lot Order 61

79 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE Process Input Output Process Cutting Assembly Job/Lot Order Finished Goods Finished Goods Quality Assurance Finished Goods Qualified Goods Package Qualified Goods Packaged Goods Product Inventory Control Packaged Goods Product Product Material Handling Product Product Delivery Order Shipping Product Delivery Order Invoice WSDL service description When a business process is virtualized as a self-contained Web service, the input message as well as output message of this business process should obey rigorously the SOAP protocol. Specifically, the data to be exchanged with the business process have to be wrapped within a SOAP envelope, which is essentially an XML document. In order to model different types of massages, we define the XML schema ICIS.xsd for all data types. The schema is further added to WSDL service description for each Web service. Figure 4.4 shows the WSDL description of Issue Purchase Order Web service. 62

80 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE Figure 4.4 WSDL description for Issue Purchase Order Web service Figure 4.5 shows the XML schema of Issue Purchase Order Web service. A complex type element named customer request [Customer Request] includes three 63

81 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE nested complex type elements: [CustomerInfo], [Payment], [Items] and a generic element: [RequestDate]. A complex type element named [ProductPO] includes a nested complex type element [CustomerRequest] and a generic type [OrderDate]. 64

82 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE Figure 4.5 XML schema for Issue Purchase Order Web service 65

83 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE Web service implementation After defining the operation and binding information, the corresponding WSDL service description is therefore fully operational and can be implemented and deployed. Model driven tools such as WSDL2Java support the contract-first approach to implement and deploy Web services from WSDL service descriptions. In a nutshell, WSDL2Java produces the Java code necessary for building stubs, skeletons, and data types. The only thing service developers need to do is to extend skeleton Java classes by adding specific code in order to implement the business logic. The underlying technical details of Web services platform and engine are transparent during the implementation process. Web services platform such as Apache AXIS2 < provides a convenient mechanism for developed Web services. The code-first approach can also be used for the cases where the Java codes, especially the service interfaces are already available or want to be first developed. In this case, Java2WSDL tool is applied to generate the corresponding WSDL descriptions. This approach enables a convenient integration of legacy systems. It should be noticed that both approaches rely on the identification of service interfaces. We adopt the contract-first approach and design services interface using WSDL as it provides a standard and platform-independent way of building Web services. 66

84 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE 4.3 Semantic rich service-oriented manufacturing CVE In a service-oriented manufacturing CVE, service provider and service requester may come from different countries with different culture backgrounds. They may use different languages and have different knowledge expression habits, let alone vagueness of manufacturing terms themselves. The service-oriented environment can be enhanced with rich semantics using Semantic Web technologies. Two core technologies are crucial for creating semantic rich environments: ontologies (upper ontologies and domain ontologies) and standard languages for developing ontologies. Manufacturing knowledge exists in all aspects of manufacturing and can be captured at the different levels of generality. The corresponding ontologies typically include domain ontology, value chain ontology, and product life cycle ontology. A domain ontology classifies the most general information that characterizes an entire domain. For example, a domain ontology would include general information about products, manufacturing techniques and tools, and so forth, applicable across the entire manufacturing domain. A value chain ontology include the general information about entire value chain involved in a certain manufacturing sector (semiconductor, for example). A product life cycle ontology has more specific information for a life cycle of a product and covers activities for implementation of production planning and control (product design, process design, layout design, production plan and scheduling plan), including information about all relevant kinds of objects, properties, 67

85 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE and relationships for that product. These manufacturing ontologies are developed using OWL. The need to create a shared understanding (i.e., ontologies) for an application domain such as manufacturing section is long recognized. When creating ontologies, there are many issues that need to be addressed under the umbrella term "ontology engineering" which are beyond the scope of this research. In this chapter, we discuss the use of ontologies by focusing on how they are used for our main research concerns. In order to bring semantics to Web services, a standard approach is to use OWL-S, a OWL-based Web service upper ontology, and domain ontologies (also in OWL) as shown in Figure 4.6. Figure 4.6 OWL-S: an upper ontology for Semantic Markup for Web Service To illustrate the enhancement of a Web service with semantics, we take Table 4.1 as example which also highlights the inputs and outputs of each service in 68

86 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE manufacturing CVE. Table 4.1 also highlights the inputs and outputs of each service in manufacturing CVE. For example, the input of the Process Product Purchase Order service (C2) is a Product Purchase Order. After executing C2, a Manufacture Order (the output) is returned and will be later feed into another service (i.e. Schedule Production service P1). To automate semantic based services discovery and composition, OWL ontology has been designed in order to capture the relationships between various types of inputs and outputs as shown in Figure 4.7. For illustration purpose, the OWL ontology to model Product Purchase Order and Manufacture Order has been depicted in Figure 4.8 using UML formalities. 69

87 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE Figure 4.7 Ontology for information flow of manufacturing CVE 70

88 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE Figure 4.8 Partial view of ontology 4.4 Semantic Web Services for manufacturing CVE As mentioned above, the manufacturing CVE can be implemented as Web services through service virtualization. Once the domain OWL ontology for manufacturing CVE is available, the Web services can be further augmented to semantic Web services which can facilitate automation of service discovery, selection, composition and invocation. In this research, we propose the use of OWL-S to describe the services in manufacturing CVE. Figure 4.9 shows the OWL-S description of IssuePurchaseOrderService which is described using IssuePurchaseOrderProfile, such that it can be discovered, matched by the client application that invoked this service. The IssuePurchaseOrderGrounding (Ref section 4.4.1) describes how to access the services provided by IssuePurchaseOrderProcess. The IssuePurchaseOrderProcess described how the process works by specifying the process model including inputs, outputs, pre-condition and result (IOPR). Figure 4.10 shows the manufacturing service instances such as Issue_Purchase_Order_Service, 71

89 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE Process_Product_Purchase_Order_Service, Shipping_Service etc. in our service oriented manufacturing CVE. 72

90 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE. Figure 4.9 OWL-S description for IssuePurchaseOrderService 73

91 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE Figure 4.9 OWL-S description for IssuePurchaseOrderService (continued) 74

92 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE Figure 4.9 OWL-S description for IssuePurchaseOrderService (continued) 75

93 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE Figure 4.9 OWL-S description for IssuePurchaseOrderService (continued) 76

94 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE Figure 4.10 Semantic Web services for manufacturing CVE 77

95 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE Automatic execution of OWL-S service Automatic execution is one of the goals of Semantic Web service. In order to enable automatic Web service execution, it requires a human to understand what information is required to execute the service and to interpret the information the service returns. Semantic Web service OWL-S employs a standard ontology for declaring and describing services in terms of a set of basic classes and properties. It provides the semantics of the arguments to be specified when executing these calls, and the semantics of what is returned in messages when the services succeed or fail. Therefore automatic execution of Semantic Web service enables users and software to invoke, compose, and monitor web resources offering particular services and having particular properties with a high degree of automation. In OWL-S, the service profile defines the service specification such as functional properties, quality guarantees, etc, allowing an agent to determine whether the service meets the goals. On the other hand, the service model provides the details of the semantic content of request, the conditions under which particular outcomes will occur, to tell the client how to interact with the service correctly. However, the information from service profile and service model does not contain the concrete information such as the details of how to access the service involving communication protocol, message format, serialization, transport and addressing. Therefore, the client cannot automatically invoke the underlying Web service only based on the OWL-S service profile and process model. 78

96 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE To achieve automatic execution of OWL-S service, we need grounding a service to a concrete realization. A service grounding can be thought of as a mapping from OWL- S service to a target Web service. Specifically, it is a mapping between abstract types of OWL-S and WSDL. This is because OWL-S defines the abstract types as OWL classes while WSDL specifies abstract types using XML Schema (XSD). Therefore, a mapping mechanism is required in order to realize automatic Semantic Web service execution. As shown in Figure 4.11, the mapping mechanism is basically consisted of two transformations: Inbound transformation is responsible for converting the OWL-S input OWL classes to the WSDL request messages when sending request to Web service. Outbound transformation is responsible for converting the WSDL response messages to the OWL-S output OWL classes when receiving response from Web service. Figure 4.11 OWL-S and WSDL mapping mechanism 79

97 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE The key of mapping the OWL-S service to the underlying WSDL Web service is how to map the OWL-S input/output OWL classes to the corresponding WSDL request/response messages that defined in XML Schema. To solve the inbound/outbound transformations in the service grounding for automatic execution purpose, an XSLT script is required to transform OWL classes to and from XML Schemas. In Figure 4.9, IssuePurchaseOrderGrounding describes how to access the IssuePurchaseOrderService. The scripts in two red rectangles are the XSLT transformations that convert CustomerRequest OWL class to WSDL input messages and WSDL output message to ProductPurchaseOrder OWL class Framework of automatic execution of OWL-S Service The OWL-S API provides a Java programmatic access to read, write and execute OWL-S service descriptions, which is used as the runtime environment to enable the automatic execution of OWL-S service. Figure 4.12 shows the framework of automatic execution of OWL-S service. 80

98 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE Figure 4.12 Framework of automatic execution of OWL-S service The detail runtime interactions occur in the automatic execution of OWL-S atomic process are described as following: 1. OWL-S client initializes the execution of atomic process by passing the URL of OWL-S description file to the OWL Inference Engine. 2. OWL Inference Engine reads the OWL-S file and parses it into OWL-S service ontology, such as service ontology, process ontology, etc. It is also responsible for loading additional ontologies which can help the interaction. 3. OWL-S client gets the input class of the atomic process from process ontology and initializes it accordingly, finally passes the process and input class to the OWL-S Execution Engine. 4. The OWL-S Execution Engine transforms the input of the OWL-S atomic process to the corresponding request message of the WSDL operation based 81

99 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE on the OWL-S grounding, and then sends the request message to the Web Service Invoker. 5. The Web Service Invoker received the request message and constructs the SOAP request message to invoke the Web service using AXIS framework. 6. The AXIS2 Web Service processes the SOAP request, executes the business logic and returns the SOAP response to the Web Service Invoker. 7. The Web Service Invoker passes the SOAP response to the OWL-S Execution Engine. 8. The OWL-S Execution Engine transforms the SOAP response to the corresponding output of the OWL-S atomic process based on the OWL-S grounding, and then sends the output to the OWL-S client. 4.5 Summary In this chapter, a traditional manufacturing workflow has been introduced first followed by a service-oriented manufacturing CVE. The key step required to utilize Semantic Web technologies for manufacturing domain is virtualization of process and activities in manufacturing domain as Web services using service-oriented architecture. A collection of Web services are developed based on the manufacturing CVE scenario. They are further annotated with OWL-S upper ontology and domain ontologies to become a collection of Semantic Web services. Finally, the framework of automatic execution of OWL-S atomic service has been presented. 82

100 Chapter 4: Semantic Rich Service-oriented Manufacturing CVE With manufacturing process and activities represented as Semantic Web services using service oriented architecture, the main advantages of CVE are: 1) it makes company focus on its core competencies and outsource other manufacturing processes to key partners; 2) it increases a company s flexibility by linking complementary core competencies of participating organizations; 3) it reduces cost of investment and generate high profit margins; 4) it makes manufacturing system modular, adaptable and flexible to quickly response to the changing market and operation environment; 5) it facilitates automation of service discovery, selection, composition and invocation. 6) it can leverage on globally available services or infrastructures that more effectively serve the business goals and more cost effective. 83

101 5 Web Service Composition Chapter 5: Web Service Composition In this chapter, the service-oriented integration architecture for CVE is introduced first. Within the service-oriented paradigm, two representative approaches BPEL and OWL-S are investigated to realize service composition in a service-oriented manufacturing CVE. The critical analysis of BPEL and OWL-S is conducted in the manufacturing CVE scenario. Five key criteria for evaluating technologies of service composition are identified. Moreover, semantic-driven services composer based on OWL-S is developed and the goal-oriented forward-chaining algorithm is presented. The structure of the chapter is as follows: in section 5.1, a service-oriented integration architecture for CVE is presented; in section 5.2, two strategies of service composition - BPEL and OWL-S are introduced; in section 5.3 and 5.4, service composition in service-oriented manufacturing CVE using BPEL and OWL-S approaches are presented in details separately; based on the two prototypes, comparison study is further presented in section 5.5. Section 5.6 gives a summary. 5.1 Service-oriented Integration Architecture The semantic-enhanced service-oriented CVE pre-assumes a general and scalable integration architecture (Yang et al. 2006) as shown in Figure 5.1. Fundamental to the service-oriented integration is the virtualization layer. Via virtualization, all systems, applications, services and equipments to be integrated in the collaborative virtual enterprise are exposed as Web services, and they can offer their services and 84

102 Chapter 5: Web Service Composition functionality in a standard Web service environment. The basic Web service infrastructure (SOAP-WSDL-UDDI) is augmented with business process execution service to support dynamic business process execution. It forms the services infrastructure layer. All the services newly developed or those obtained from the virtualization will be enhanced with domain specific semantic information. As stated above, the emerging Semantic Web standards provide the Web services infrastructure with the semantic interoperability that integration needs. The semantic based services description is unambiguously computer interpretable and facilitates maximal dynamism in Web service discovery, selection, composition, and invocation. In a way, Semantic Web transforms the Web service infrastructure into repository of computer manipulatable data with rich semantics. Architecturally, this is achieved in the semantic enhanced Web services layer. Figure 5.1 The service-oriented integration architecture for CVE The ultimate objective of this dynamic integration architecture is of course to fulfill the business goals for which the CVE is formulated. The essence of business process 85

103 Chapter 5: Web Service Composition modeling is to create a coherent, integrated (and interoperated) business process for achieving enterprise s ultimate strategic business goals. In a sense, the coherent business processes provide a process perspective of the CVE. In order to achieve dynamic integration in CVE, it is necessary to realize the business goals in the form of business process through service-oriented process models. This service-oriented process is a high-level description of what to be done in terms of a sequence of services, that is, a service process. The service process will be realized via service composition (orchestration) and choreography. Web services composition is concerned with connecting Web services together to create higher-level business processes that are typically executed by a single party. For orchestration, the process is always controlled from the perspective of one of the business parties. On the other hand, choreography is more collaborative in nature when business or other activities involve multiple different organizations. 5.2 Strategies of service composition In a service-oriented environment, many different business partners expose their functionalities as Web services. There is a requirement to have the ability to define logic over a set of service interactions. Some standards in the industrial category were developed to define business process behavior by orchestrating Web services, such as Web Services Business Process Execution Language (WS-BPEL) (Alves et al. 2006), Web Service Choreography Description Language (WSCDL), Web Service Choreography Interface (WSCI) and Business Process Modeling Language (BPML) 86

104 Chapter 5: Web Service Composition (Hull and Su, 2005). Among them, we believe BPEL is the most matured technology with a complete bundle of software tools and running environments catered for business environments. BPEL is an XML language for process-oriented service composition which combines the IBM Web Service Flow Language (WSFL) and Microsoft XLANG. It is developed by IBM, Microsoft, BEA, SAP and Siebel. The current version is BPEL4WS 1.1, the next version, renamed as WS-BPEL 2.0, was submitted to the Organization for the Advancement of Structured Information Standards (OASIS) and is still in the standardization process. Comparing with Web Services which use stateless interaction model, business processes which are defined in BPEL and built on WSDL represent stateful longrunning interactions through Web Service operations. Whenever a client starts a new business process, a new instance of that process is created and lasts until the instance ends. During its lifecycle, a business process instance might communicate with other business partners. It is important to have a message correlation mechanism to guarantee that messages are delivered to the correct instance of the business process (Benatallah et al. 2002). It is noteworthy that the various industrial standards mainly focus on the syntactic aspects of Web Service composition (Lara et al. 2005). They are lack of effective tools to support flexible service discovery and dynamic service composition, resulting in slow response to the change of customers and market requests. The research 87

105 Chapter 5: Web Service Composition community seeks to address these issues through introducing semantic-rich languages for high-level services description. One representative technology is OWL-S, which is a major outcome of a collaborative research effort involving Carnegie Mellon University, Stanford University, University of Maryland, SRI International, Nokia, etc. To realize Semantic Web Services, OWL-S was proposed to facilitate the automation of Web Service tasks including service discovery, execution, interoperation, composition and execution monitoring (OWL-S Coalition, 2004). It is a collection of loose upper ontologies and is description oriented. It focuses on capabilities, functional properties, and other non-functional properties (such as QoS). The behavior of a Web service is modeled with a process/action paradigm rooted in situation calculus. Inputs and outputs of a service are named and typed using either OWL-S ontologies or data types that XML Schema provides. They together constitute the main interface for the purpose of interacting with the service (Yang et al. 2006). The current version of OWL-S builds on top of OWL which is the most expressive of the ontology language based on RDF, RDF-S, DAML + OIL. As a first step towards deeply understanding the service composition problem, we attempt to achieve integration in service-oriented manufacturing CVE using two different approaches. One is driven by industrial application BPEL, the other is inspired by the booming research development in Semantic Web OWL-S. 88

106 Chapter 5: Web Service Composition 5.3 WSBPEL approach We choose Oracle s JDeveloper and its BPEL Process Manager as our development tools because they are more stable and powerful tools with friendly GUI. Oracle JDeveloper is a free integrated development environment with end-to-end support for modeling, developing, debugging, optimizing, and deploying Java applications and Web services. BPEL Process Manager provides an environment for creating, deploying and managing BPEL business processes. Before deploying and testing a BPEL process, we need install the Oracle SOA including BPEL Process Manager to setup the environment for BPEL processes. The tool can manage all the BPEL processes deployed on the server; monitor all the messages exchanged between BPEL processes and Web services, keep all instances data of BPEL processes. Let s take a sub-workflow in manufacturing CVE as an example to illustrate the service composition via WSBPEL approach. The details are shown in Figure 5.2. This sub-workflow mainly processes the customer s request to generate material consumption list, engineering specifications and product specifications. Customer s request [CustomerRequest] will be firstly sent to Issue Purchase Order Web service which will process the request and return product order [ProductPO] as output. The product order is then passed to Process Product Purchase Order service which will output manufacture order [ManufactureOrder]. And finally the Schedule Production service will process manufacture order and generate material consumption list [MaterialRequest], engineering specifications [EngineeringRequests], product 89

107 Chapter 5: Web Service Composition specifications&schedules [ProductSpecificationSchedule]. These parameters will be sent to its following workflow. The input/output messages like [CustomerRequest], [EngineeringRequests], etc., are complex data types defined in a schema file as mentioned in chapter 4. Figure 5.2 Sub-workflow in manufacturing CVE Figure 5.3 shows the graphic BPEL process for Process Product Purchase Order service designed using BPEL Process Manager. The process contains a <receive> activity to get the input message from the client to start the process and a <reply> activity to return the result synchronously to the client. A BPEL <assign> activity provides a mechanism for doing simple data manipulation, using XPath expressions. Here, we use the <assign> to copy data from the input message to BPEL variables and copy the result to the output message. A <partnerlink> is created to define the Process Product Purchase Order service that the process will interact with. The correspondent BPEL source code for Process Product Purchase Order service is depicted in Figure

108 Chapter 5: Web Service Composition Figure 5.5 presents the BPEL process for the sub-workflow. Three <partnerlink> are created for the interaction with Issue Purchase Order, Process Product Purchase Order and Schedule Production services correspondently. The generated BPEL source code for the sub-workflow is presented in Appendix. Figure 5.3 BPEL process for Process Product Purchase Order service 91

109 Chapter 5: Web Service Composition Figure 5.4 BPEL source code for Process Product Purchase Order service 92

110 Chapter 5: Web Service Composition Figure 5.5 BPEL process for sub-workflow in manufacturing CVE 93

111 Chapter 5: Web Service Composition 5.4 OWL-S approach In this CVE scenario, the service process is conveniently described in OWL-S with IOPR. The service composer implementation involves service discovery (matchmaking), the service selection is governed by the composeability characterization, and finally composition of Web services that realize the service process. A semantic-driven service composer is the core of OWL-S approach. As we believe, the technical challenge of CVE, which is to fully support dynamism and agility in enterprise integration, demands for composers that can operate without or with limited human intervention. Service upper ontologies and domain ontologies will enrich Web services with semantics. Upon receiving user s requests, a services composer that utilizes such semantic information will dynamically forge a business process, which is consistent with the business process model that serves as the design input. It typically relies on a Semantic Web service discovery component, which describes how to evaluate a degree of similarity between a service requirement and an actual service instance by measuring the syntactical, operational, and semantic similarity (Tang, 2004). In this section, we will first introduce the characterization of services composeability. Then the semantic-driven service composer based on the forward-chaining algorithm is presented and implemented. Its successful use in a prototyped enterprise 94

112 Chapter 5: Web Service Composition manufacturing CVE further exemplifies the practicality of Semantic Web Service technologies in supporting CVE Characterizing Services Composeability Service-orientation opens a new window for enterprise integration via service composition. However, to what extent services can be composed together to solve the integration issue depends on the composeability of these services, that is, the ability for them to participate in and contribute to the composition. In a sense, composeability seeks to describe the interrelations between services and how to assemble them so as to offer a value-added service. In view of service composition, it is often convenient to transform composeability into a problem of deciding when one Web service matches what we want. There are various types of semantic matches. While exact match between services (or between service and requirements) appears to be the best choice, many flavors of relaxed match may also serve the purpose. The characterization of matches requires the semantic description of Web services in OWL-S. Two aspects of service behavior described in OWL-S are of particular interests to services matching: (1) the information transformation represented by inputs and outputs, and (2) the state change produced by service execution in the form of preconditions and results. This together is known as IOPR (Input/Output/Precondition/Result). Inputs and outputs of a service are named and typed using either OWL-S ontologies or data types that XML Schema provides. They together constitute the main interface 95

113 Chapter 5: Web Service Composition for the purpose of interacting with the service. The semantic-driven services composer in this work is based primarily on the input and output descriptions of a service. In our previous research, we have characterized 14 different matches derived from IOPR (Yang et al. 2006). Nevertheless, in this work we will only highlight several matches that are explicitly utilized by our current implementation of the composer. match A, B Definition 1 (Exact-IO-Match): EIO( ) outputs inputs = A B Service A is said EIO-matched with service B if and only if each input of service B has corresponding matched partner in service A s outputs. match A, B = A B Definition 2 (Input-Match): Input ( ) inputs inputs Service A is said I-matched with service B if and only if each input of service B has corresponding matched partner in service A s input. match A, B B Definition 3 (Output-Match): Output ( ) outputs outputs = A Service A is said O-matched with service B if and only if each output of service B has corresponding matched partner in service A s outputs. The input/output match is based on semantic matching which contains four degrees: Exact, Subsume, Relaxed, and Fail (Paolucci et al. 2002) as shown in Table 5.1. Suppose that we are matching one output Ou1 of service A with another input In2 of 96

114 Chapter 5: Web Service Composition service B. Further assume that Ou1 is typed using ontology C1 and In2 is typed using ontology C2. The four matching degrees between Ou1 and In2 are summarized in Table 5.1. Table 5.1 The four degrees of semantic matching (Paolucci et al. 2002) Based on the matches between the inputs and outputs of different services, a composite service execution sequence (or composite service) as shown in Figure 5.6 is expected to be produced by a services composer. Nodes in Figure 5.6 represent services. Edges connect services if the output of a service can be feed into the input of another service. The control flow as well as the data flow is determined by the direction of edges. For example, in Figure 5.6, service A must be executed first before performing service C, to which the edge starting from A points. Besides, for those services whose inputs are not linked with the outputs of other services, they are termed starting services (e.g. service A and B in figure 5.6). Their inputs will serve as the inputs of the composite service. Likewise, for those services whose outputs are not linked to any inputs of other services, they are termed ending services (e.g. 97

115 Chapter 5: Web Service Composition service D in figure 5.6). To make this service composition problem less complicated, we assume that the sequence as shown in Figure 5.6 must form a feed-forward graph without any loops or self loops. Figure 5.6 A composite service execution sequence Architecture of the semantic-driven service composer Figure 5.7 shows the architecture of the semantic-driven service composer. The input to the composer comprises (1) the requested service capability from the service consumer and (2) all advertised services imported from the OWL-S repository. In current implementation of service composer, the requested service capability refers primarily to the required outputs of a service given the available inputs. The OWL-S repository stores the services advertised by Service Providers. To import the services from OWL-S repository into service composer, the OWL-S API library is used which is developed by University of Maryland. The output from service composer is a composition sequence (Ref. Figure 5.6) which consists of one or more component services. The component services will be executed based on the control flow so as to achieve the requested capability. Evidently after employing a SC component in a 98

116 Chapter 5: Web Service Composition service-oriented CVE, the OWL-S approach realizes the business process model together with the flexibility and dynamicity desirable for enterprise integration. Figure 5.7 The semantic-driven service composer Service Composition Algorithm As depicted in Figure 5.7, the central part of Composite Engine is a forward-chaining engine, the main responsibility of which is to find new candidate services S service based on the current set of derived outputs S outputs and given inputs S inputs. An output 99

117 Chapter 5: Web Service Composition is termed derived if the corresponding service was identified via the forward-chaining process. Iteratively, all derived outputs are checked against the requirements imposed by service consumers (the composition requirement evaluator in Figure 5.7). Specifically, when every required output is among the set of derived outputs, a composite sequence is generated and returned to service consumers (the composite sequence generator in Figure 5.7). Otherwise, if forward-chaining cannot proceed further because no new candidate services can be identified, a composition failure is returned. Notice that the Composition Requirement Evaluator in Figure 5.7 works according to the ontologies and semantic based service descriptions. As a result, a required output Ou is considered satisfied if there exists a derived output Ou that semantically matches Ou. A detailed description of this service composition process is given in Figure

118 Chapter 5: Web Service Composition Figure 5.8 The forward-chaining service composition algorithm. Following the procedure in Figure 5.8, the forward-chaining process continues until all the required outputs have been identified. Take a sub-workflow of a manufacturing CVE as an example (Ref. Figure 4.2). Suppose that the available input to the composer is the manufacturing order, and the required output is the daily 101

119 Chapter 5: Web Service Composition schedule. Table 5.2 lists the newly added outputs to S outputs during each round of forward-chaining. Table 5.2 The newly added outputs to S outputs during each forward-chaining round (the requested output is reached at round 5) Composite Sequence generating Algorithm The last step in the forward-chaining service composition algorithm demands that a composite sequence be generated from S inputs, S outputs, S service, and S start. This can be achieved through a backward chaining process as depicted in Figure 5.9. The obtained composite service execution sequence is shown in Figure Suppose that we have newly created a Web service P, which is able to produce daily schedule upon given a manufacturing order. When P is added to the OWL-S service repository, the composer is able to produce a composite service sequence that is much 102

120 Chapter 5: Web Service Composition simpler, containing only a single service P. It shows that the composer can cope with the dynamism in Web service environments. Figure 5.9 The composite sequence generating algorithm. 103

121 Chapter 5: Web Service Composition Figure 5.10 The composite service sequence obtained through the services composer. 5.5 Comparison study In this section, we present a comparison study of two different service composition strategies based on the two prototypes. Five key requirements for evaluating service composition have been identified. To meet the full challenge of dynamic service composition at the enterprise level, an attempt has been made to evaluate BPEL and OWL-S through the service-oriented manufacturing CVE scenario Service Composition Requirements We choose these five dimensions because they are most relevant to CVE, which is our main research area. Similar dimensions have also been identified recently in the literature (Alonso et al. 2004; Dustdar and Schreiner, 2005). Component Model: Services can be seen as a set of network endpoints. In a service composition, each component service should be able to be defined in a 104

122 Chapter 5: Web Service Composition structured way to identify its nature (Alonso et al. 2004). As a general requirement, component model should be able to describe the type of component services and service interface. Orchestration Model: In a service composition, orchestration describes the way in which different services can be brought together into a coherent composite service to provide a value-added service. It is realized by control flow constructs that specify the order in which individual operations of services are executed, and the conditions under which a certain service may or may not be invoked (Alonso et al. 2004). One composition language should provide the control constructs to define logic over a set of service interactions. To support a variety of practical composition requirements, control construct in many aspects should resemble a programming-language. Specifically, the control construct should be able to break up the flow of execution by employing decision making (if-then-else, switch), looping (while, for), and branching (break, return, continue), enabling the composed service to conditionally execute particular operation. Therefore, control flow is one of the essential requirements for service composition. Data and Data Flow Model: Service components interact with each other by exchanging data which should be defined and accessed in an explicit way (Alonso et al. 2004). From service composition point of view, data flow refers to the flow of information in a composed service. One composition language 105

123 Chapter 5: Web Service Composition should provide means to define data, to describe how data can be exchanged between component services being composed, and to describe inputs and outputs of the composed service. Error Handling and Transactions: It is desirable for a composition system to offer an efficient and effective error handling and compensation mechanism. Such mechanism will help to identify faults (i.e. error handling mechanism) and undo work that is partially or successfully completed (i.e. compensation mechanism). When error occurs during execution, the system can deal with exceptional behavior to guarantee system stability. Quality of Service (QoS): With the increase of Web Services as a business solution to enterprise application integration, the quality of service (QoS) offered by Web Services will become more and more important for service providers and their partners. A better QoS for a Web Service will make it more competitive than others. Therefore, it is desirable to carry the quality of service information which is a key non-functional property for service composition A Scenario High level service process in service-oriented manufacturing CVE Our comparison study will be illustrated through a service-oriented manufacturing CVE. A high-level service process of the manufacturing CVE is shown in Figure

124 Chapter 5: Web Service Composition Figure 5.11 High level service process in an manufacturing CVE From the functional perspective, our CVE system aims at automating the manufacturing process after receiving customer s requests. Its proper operation relies essentially on the collaboration of various functionalities (e.g. production scheduling, product engineering, material management, manufacturing, and shipping etc). Each of the functionality is virtualized through one or multiple Web services. A functionality in the high level service process is itself a composite service if it is virtualized through multiple Web services. For example, Plan Schedule component is virtualized through several Web services including Plan Master Product Schedule service, Plan Material service, Plan Capacity service and so on as show in activity diagram The Plan Master Product Schedule service creates the weekly production plan and calculates the Required Capacity and Required Stock Material. The Plan Capacity and Plan Material services evaluate the initial production quantities to determine whether sufficient capacity and material exist. As we can see in Figure 5.12, Plan Master Product Schedule service and the other two services (Plan Material and Plan Capacity) are in the sequence order. Plan Material service and Plan Capacity service can be executed in parallel. 107

125 Chapter 5: Web Service Composition Figure 5.12 Plan Schedule Composite Service Comparison In the sequel, we will compare BPEL and OWL-S based on the five requirements identified in section In each subsection, we will first discuss BPEL followed by OWL-S Component Model In BPEL, the components are WSDL services. The result of composite service is called process. The external participating Web service that interacts with the business process are called partner. BPEL defines <partnerlinks> for describing the behavior of a business process based on interactions between the process and its partners. WSDL is used to describe the service interfaces for participating partner (Alves et al. 2006). A BPEL process is composed of a set of basic or structured activities. A basic activity is an actual component which describes elemental step of the business process behavior. A structured activity provides higher-level business logic and combines 108

126 Chapter 5: Web Service Composition multiple basic or structured activities. They can be nested and define the order in which a set of activities is executed. In contrast with BPEL, OWL-S uses an upper ontology to describe Web Services. It consists of three types of knowledge about a service (OWL-S Coalition, 2004): ServiceProfile (what the service does), ServiceModel (how the service works), ServiceGrounding (how the service is accessed). The class SERVICE provides an organizational point of reference for a declared Web service (OWL-S Coalition 2004). For each distinct published Web service which has a distinct address for communication, there exists an instance of SERVICE class. Each instance of a SERVICE will present a ServiceProfile description, be describedby a ServiceModel description, and support a ServiceGrounding description as shown in Figure Figure 5.13 Top level of the OWL-S service ontology [Taken from (OWL-S Coalition 2004)] The ServiceProfile provides a concise description of the service to a registry in order to facilitate the search process, but once the service has been selected the Profile is 109

127 Chapter 5: Web Service Composition useless. The client will use the Process Model to control the interaction with the service (OWL-S Coalition, 2004). Both the ServiceProfile and the ServiceModel are abstract representations in OWL-S. Only the ServiceGrounding is the concrete level of specification which defined the details of how to access the service involving communication protocol, message format, serialization, transport and addressing. OWL-S makes use of WSDL as grounding mechanism. An OWL-S atomic process corresponds to a WSDL operation; the input and output sets of an OWL-S atomic process correspond to WSDL s message; the types (OWL classes) of inputs and outputs of an OWL-S atomic process correspond to WSDL s abstract types. The grounding connects the implementation of a Web Service with its semantic description. It is noteworthy that each component service which is also described as OWL-S file has the same structure as the composed one. Comparison With regard to grounding a service to a concrete realization, OWL-S provides a mapping mechanism between OWL-S and WSDL. Very often, an XSLT script is needed to derive message part from one or more inputs/outputs of the OWL-S atomic process and vice versa. However, there are no tools currently available to help generate the scripts to perform the transformation between two typing mechanisms, OWL s class and XML Schema respectively. In particulars, Web Service developers need special knowledge about ontology to annotate OWL-S services, therefore the 110

128 Chapter 5: Web Service Composition correspondent efficient tools turn out to be very on-demand, especially when the ontology becomes complex. In contrast to OWL-S, BPEL directly uses WSDL binding without transformation of typing mechanisms due to its dependency on XML Schema which is the same typing mechanism as WSDL. In addition, originated from workflow management system, BPEL inherited the absence of flexibility and dynamicity in service composition. Although BPEL provides the mechanisms to bind partnerlinks dynamically, very often, the task of binding service partners to actual service instances is done via WSDL porttype that is static and inflexible. That means at design time, partners are already bound to the actual service instances. When the BPEL process is deployed, the actual service instances participating in the orchestration are known right away and cannot be changed dynamically Orchestration Model BPEL allows the definitions of structured activities, which combine multiple basic or structured activities to define order in which a set of activities are executed (Alves et al. 2006). Figure 5.14 shows the simplified snippets of control flow in BPEL for the composition of three services in Figure The <sequence> structured activity (line 1) indicates the following activities (<receive>, <invoke> activity and <flow> structured activity) are executed sequentially. The <receive> basic activity (line 2) waits for receipt of a message from a partner clientpl via the predefined operation process. The <invoke> basic activity (line 4) is used to invoke PlanMasterProductSchedule operation offered by a service. The <flow> structured 111

129 Chapter 5: Web Service Composition activity (line 7) defines the two <invoke> activities (PlanMaterial and PlanCapacity operations at line 10 and 14) which should execute concurrently. Other structured activities in BPEL include <if>, <while> and <pick> activities. Figure 5.14 An example of Control Flow in BPEL The OWL-S process upper ontology provides similar control constructs as BPEL. The ServiceModel describes the execution of a service in details (OWL-S Coalition, 2004). A detailed perspective of a service can be viewed as a Process which is defined as a subclass of the ServiceModel. This part of OWL-S describes the service interaction protocol according to the flow of data and control between services. OWL-S defines three subclasses of Process. Atomic processes have no subprocesses and can directly execute in a single step which correspondents to the invocation of a Web service operation. Each atomic process is associated with a grounding that defines the details of how to access the service. Simple processes are not associated with grounding and are single-step executions. They are used as abstraction elements for either atomic or composite processes. Composite processes can be decomposed into other processes 112

130 Chapter 5: Web Service Composition by using control constructs such as Sequence, If-then-else, Split, Split + Join, Choice, Any-Order, Condition, Iterate, Repeat-While, and Repeat-Until (OWL-S Coalition, 2004). Figure 5.15 shows the snippets of control flow in OWL-S for the composition of three services in Figure The Sequence control construct (line 1) indicates the following component processes (PlanMasterProductSchedule at line 5 and Split- Join component starting at line 10) can be executed sequentially. The Split-Join control construct (line10) defines concurrent execution of two process components (PlanMaterial at line 14 and PlanCapacity at line 19). Figure 5.15 An example of Control Flow in OWL-S 113

131 Chapter 5: Web Service Composition Comparison As we can see from Figure 5.14 and Figure 5.15, there is an analogy between the BPEL process model and OWL-S process model. Notice that the OWL-S process model has a recursion format in its ControlContrustList element (line 3 in figure 3.5). In large enterprise applications, it is necessary for the ControlConstructList element to introduce many levels of cascading in order to hold its constituent services. It subsequently brings some potential problems. For example, the composite OWL-S file is (1) difficult to understand, (2) inefficient to parse, and (3) error prone. In addition, executing process that relies on conditionals such as If-Then-else and Repeat-Until is not supported in the widely-used Mindswap OWL-S API implementation we adopted in our project Data and Data Flow Model Variables in BPEL provide means to maintain the state of a business process which includes the messages that are exchanged as well as intermediate data used in business logic and in composing messages sent to partners (Alves et al. 2006). BPEL variables which are declared by a name and type are similar to variables in programming languages. BPEL uses three kinds of variable declarations: WSDL message type, XML Schema type, and XML Schema element. The <assign> activity (line 6) can be used to copy data from one variable to another as show in Figure Two variables PlanMasterProductSchedule-Output (line 1) and RequiredStockMaterial-Input (line 3) are declared as WSDL message type. The 114

132 Chapter 5: Web Service Composition first variable is the output of Plan Master Product Schedule service. And the second one is the input of the following component service Plan Material. BPEL realizes the input/output mapping through <assign> activity by copying data from PlanMasterProductSchedule-Output variable to RequiredStockMaterial-Input variable. Figure 5.16 An example of Data Flow in BPEL In OWL-S, a composite process is one that maintains some state; each message the client sends advances it through the process (OWL-S Coalition, 2004). A process can produce some new data based on data it is given and the world state. The data transformation is described by the inputs and outputs of the process. Moreover, a process can make a state change in the world. The state transition is described by the preconditions and results of the process. When defining a composite process, we need to describe how the output of a process component can be mapped into input of the following step. The input and output parameters can be declared as XML Schema 115

133 Chapter 5: Web Service Composition data types or OWL classes (i.e. concepts). Figure 5.17 shows the snippet of specifying data flow and variable bindings in OWL-S. Figure 5.17 An example of Data Flow in OWL-S The composite process PlanScheduleProcess (line 1) has an input ProducSpecification-Schedule (line 3) which is declared as a string type (line 5) in XML Schema. One of its outputs is DailySchedule (line 10) which is declared as a concept in predefined ontology Manufacture.owl (line 12). Line 16 to 26 specifies the data flow from process PlanMasterProductSchedule (line 23) to process 116

134 Chapter 5: Web Service Composition PlanMaterial (line 16). That is the output variable PlanMasterProductSchedule- Output (line 24) from process PlanMasterProductSchedule (line 23) is mapped into the input variable (line 20) RequiredStockMaterial-Input. Comparison One noticeable difference between the data model of BPEL and OWL-S is the lack of semantic support in BPEL which subsequently result in manual service orchestration. While OWL-S provides semantic-rich descriptions of service to automate service composition by defining data (concept) in ontologies which support reasoning about service capability. This advantage, further, facilitates the dynamicity in service composition. Especially, when new Web Services emerge and old Web Services are not available temporarily, the enterprises involved in a service composition might change their business partners and rules to fulfill the business goal. This will require a more flexible service composition language such as OWL-S to support the dynamic orchestration. It is noteworthy that the current matching algorithm used in OWL-S service composition only focus on Input and Output of IOPR. Whether a request service matches with an advertised service depends on the Input/Output type compatibility of the two services. The algorithm reasons about the subsumption relationship between Input/Output types of the two services, subsequently leading to the recognition of semantic matches. Only four degrees of matching are generally supported, namely, exact match, plug in match, subsumes match and fail (Paolucci et al. 2002). However, 117

135 Chapter 5: Web Service Composition by exploiting the valuable information in the form of preconditions and results, it is possible to support more flexible semantic matching and service discovery (Yang et al. 2006). With regarding to the expression language, BPEL adopts XPath 1.0, a language that is widely used, easy to learn and has tremendous industry support. In contrast, OWL-S provides more flexible choices such as Semantic Web Rule Language (SWRL), RDF, Knowledge Interchange Format (KIF) and Planning Domain Definition Language (PDDL) (OWL-S Coalition, 2004). Although languages such as SWRL are very expressive, they are unfamiliar for ordinary Web Service developers. Consequently, the learning curve for the ontology languages can be steep (Timm and Gannod, 2005). Furthermore, the absence of stable, efficient and user-friendly tools to support the semantic service development hinders OWL-S from prevalence Error Handling and Compensation BPEL introduces systematic mechanisms for dealing with business exceptions and processing faults. While a BPEL process is running, faults can originate from partner services that are invoked or from within the BPEL process itself. For faults that are due to partner service invocations, the WSDL defines a fault message to be returned. Within the process, abnormal behavior can be either thrown explicitly through <throw> activity or identified by the BPEL Execution engine. BPEL fault handlers specifies activity which should be executed when a fault caught by <catch> or <catchall> construct. In addition, BPEL compensation handlers provide a 118

136 Chapter 5: Web Service Composition mechanism to specify activities to reverse intermediate results in cases where exceptions occur or a partner requests reversal (Alves et al. 2006). Snippet in Figure 5.18 shows the fault handlers in BPEL process. When a fault cannotplanmaterial (line 2) occurs, regular processing is terminated and control is transferred to corresponding faulthandlers (line 1) which uses a <reply> (line 3) activity to return a fault to the client. Figure 5.18 An example of Fault handlers in BPEL According to the OWL-S specification 1.2, no mechanisms are specifically designed for error handling and compensation. This key deficiency will result in system inconsistency because intermediate results cannot be reversed back automatically (i.e. undo the intermediate service call). Therefore it is hard to guarantee the overall system correctness Quality of Service (QoS) BPEL itself does not support QoS description. Developers are therefore suggested to extend BPEL by using WS-Policy to attach QoS policies to different parts of BPEL process (Tai et al. 2004). 119

137 Chapter 5: Web Service Composition Compared with BPEL, OWL-S service profile not only provides the functionality description of services, but also allows the description of non-functional properties of the service. One type of information is quality rating of the service. The other type of information is an unbounded list of service parameters that can contain any type of information which could be used for QoS data (OWL-SCoalition 2004). However, OWL-S doesn t provide detailed classes and properties to represent quality of service metrics (Cardoso et al. April 2004). Thus, the QoS model in OWL-S still has a lot of space to be improved. 5.6 Summary In this chapter, the service-oriented integration architecture for CVE is introduced first. Within the service-oriented paradigm, two representative approaches BPEL and OWL-S are investigated to realize service composition in a service-oriented manufacturing CVE. The critical analysis of BPEL and OWL-S is conducted in the manufacturing CVE scenario. Five key criteria for evaluating technologies of service composition are identified. Moreover, semantic-driven services composer based on OWL-S is developed and the goal-oriented forward-chaining algorithm is presented. The result of comparison shows that the business process in BPEL is pre-defined; therefore BPEL is short of flexibility and dynamicity in service composition. By describing domain concepts (IOPE) using ontology, OWL-S provides a semantic description for discovering and composing Web services automatically (Rao et al. 2006). The semantic description is unambiguously machine-interpretable. It supports 120

138 Chapter 5: Web Service Composition rigorous reasoning about service description and capability. It facilitates maximal dynamism in Web service discovery, selection, composition, negotiation, and invocation. This feature provides the sound technical foundation for achieving dynamic integration via service composition. Comparing with BPEL which has been developed for many years and almost reaches maturity, OWL-S is still in its early stage. The adoption of OWL-S hasn t been prevalent for lack of tools to support the development. Furthermore, the learning curve for the ontology languages can be steep for common developers (Timm and Gannod, 2005). Unlike OWL-S, BPEL gets more supports from industry. Currently, several BPEL orchestration servers which provide a runtime environment for executing BPEL business processes are available for both J2EE and.net platform. They are Oracle BPEL Process Manager, Active BPEL Engine, IBM WebSphere Business Integration Server, BEA WebLogic Integration, Microsoft BizTalk and OpenStorm Service Orchestrator. In addition, BPEL has correspondent process design environment with a graphical user interface such as Oracle JDevelop. It is interesting to note that recent research has shown that BPEL can leverage on the rich semantic information of OWL-S service descriptions to achieve such tasks as flexible partner binding and semantic integration (Mandell and McIlraith, 2003). 121

139 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework 6 Business Rule Enhanced Semantic Service Composition Framework In order to systematically address semantic web service composition, a business rule enhanced semantic service composition framework is further presented and analyzed. We adopt the divide-and-conquer strategy and propose a hierarchical composition architecture to handle tasks of complex service composition. In this framework, the description of each Web Service is enhanced with rule-based modeling of the essential business logic behind the service interface. A formal notion of service utilities has been provided. Complete processes for calculating the service utilities have also been introduced through processing and evaluating these business rules. A PC manufacturing CVE derived from a practical industrial setting is designed and a prototypeing system is developed to experimentally evaluate the effectiveness of our service composition framework. This chapter is organized as follows. Section 1 describes the hierarchical service composition framework. Section 2 introduces the application of business rules technology to service selection and composition. Section 3 presents a prototype system and some experiment results. Finally Section 6 summarizes this chapter. 122

140 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework 6.1 Hierarchical service composition framework The formation of a business process is generally a complex and computationintensive task. From problem-solving perspective, the complex service composition problem can be divided into multiple sub-problems driven by correspondent subgoals until the sub-problems are solvable. To make this task achievable in practice, the divide-and-conquer strategy is explored in this research via a hierarchical service composition framework. It is commonly known that services involved in a business process can be largely divided into several different categories. For example, in a manufacturing-centric CVE, a typical high-level business process (Hitomi, 1996) can be depicted as in Figure 6.1. Figure 6.1 A high-level view of the manufacturing-centric business process. As shown in the figure, customers requests are to be realized through a sequence of seven major steps. In other words, seven categories of services are jointly involved in 123

141 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework the formation of a composite service. A request will be handled first by order processing service in order to evaluate the feasibility of the request and the potential revenues it might generate. As a consequence of this evaluation, detailed requests for raw material procurement, material shipping and product manufacturing will be handled subsequently by material purchasing services, shipping services and product manufacturing services. Finally, manufactured products have to be finely packaged through product packaging services before delivering to end customers via production distribution services. It is clear to see that a business process can only be completed successfully through the orchestration of services belonging to all the seven categories. It is eligible to consider each step in Figure 6.1 as a business sub-goal which can be satisfied through performing a series of inter-related business activities. For example, Product Manufacturing in Figure 6.1 is usually comprised of a chain of business steps, ranging from raw material processing to product assembly and quality assurance. All these business steps belong to the same service category of product manufacturing. Nevertheless they are much more fine-grained since each of them will be normally implemented as atomic Web services. For this reason, the term business unit will be utilized in this work to refer to those elementary business steps in a business process. From the perspective of service composition, a business unit serves essentially as a collection of alternative services that offer identical business functionalities. One of the alternative services will be eventually chosen for executing a business process which employs the business unit as one of its internal steps. 124

142 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework In view of this, a hierarchical structure of service categories can be established. The seven components in Figure 6.1 stand for top-level service categories. Within each component, elementary service types, namely business units, can be identified and realized through Web Services. In practice, any classification of Web services in a business process is subject to the functional requirements from specific application domains. In this research work, the available service categories as well as their relationships will be modeled through OWL classes and the subclass-of property. To facilitate service classification and its ontology-based description, the following concepts will be utilized. Service Category is situated at the top of the service hierarchy and plays a very important role when classifying Web services. First of all, it provides a coarsegrained categorization of a huge number of Web services available to a CVE. In the meantime, it defines the boundary of fine-grained service classification by serving as a business sub-goal which could only be achieved through integrating of services of the same category. Business Unit is located at the middle of the service hierarchy and refers to an elementary business activity that is unnecessary to be divided into more fine-grained business operations anymore. A business unit is fundamentally identical to a black box that translates given inputs to desirable outputs. The business functionality it represents therefore is modeled through a group of service inputs and service outputs. Despite of the conceptual similarities, a business unit is different from a Web service 125

143 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework in a sense that it only exists logically with no concrete implementations. In particular, it is convenient to view a business unit as a collection of alternative Web services that share equal business functionalities. Nevertheless, each alternative service might offer significantly differed utilities to a business process. The concept of utility will be explained in the next section. Web service is positioned at the bottom of the service hierarchy. The semantics of each Web service is described by its input set, output set, precondition and result, which together are denoted as IOPR. The precondition represents the eligibility of using a web service. As a simple example, if a monitor purchasing service only accepts credit card payment, it is hence unusable should the customer requires cash payment. The result indicates the possible outcome of a service after its execution. For the monitor purchasing service, the result could be manifold, including among others that 1) requested monitors have been purchased; and 2) a certain amount of money has been deducted from the customer s bank account. Both the precondition and result of a service are closely related to the actual business the service offers and are of dynamic nature. Although they cannot be fully captured by domain-specific ontology alone, we found that a satisfactory description can be approached with the use of the business rules technology (see next sub-section). The subclass-of relationship between service category and business unit is quite obvious and will be derived directly from domain ontology engineering. Nevertheless, 126

144 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework more definitions are necessary in order to determine the relationship between business unit and Web services, as presented below. Input-Match: A business unit BU is said input-matched with Web service S if and only if each input of S matches to one of the inputs of BU. Depending on the semantic markups, there can be four major degrees of matching induced, namely exact match, plug-in match, subsumed match, and failed match (Paolucci et al. 2002). For BU to input-match with S, only exact match is acceptable. Output-Match: A business unit BU is said output-matched with Web service S if and only if each output of S matches to one of the outputs of BU. For BU to output-match with S, only exact match and plug-in match are acceptable. Figure 6.2 A hierarchical service composition framework 127

145 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework Using the definition of input-match and output-match, a service S is said to belong to a business unit BU if and only if BU both input-matches and output-matches S. In line with the hierarchical structure of service category as introduced above, service composition will be performed subsequently at three levels with semantically differed outcomes. Figure 6.2 illustrates our hierarchical service composition framework in detail. As shown in the figure, it is eligible to view a composite service, which in fact stands for a service-oriented implementation of business processes, as a directed graph. Each vertex of the graph might represent a service category, a business unit, or a Web service, depending on the actual level of service composition. On the other hand, an edge from vertex to vertex implies that the service (or business subprocess or sub-goal) as indicated by must be performed in advance of the service corresponding to. is hence termed a prerequisite of. The business activity corresponding to cannot be fulfilled before the fulfillment of all its prerequisites. Before the end of this sub-section, we discuss each composition level one by one. Composition level 1 (Service Category Level): An abstract composite service will be formulated initially at this level when a customer request arrives. Every element of this abstract composite service is a service category. It serves as the basis for the subsequent formation of concrete composite service at level two (Business Unit Level). From the problem-solving perspective, with an abstract composite service in place, complex service composition problems can be effectively divided into multiple sub-problems, each of which is much easier to solve. 128

146 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework Alternatively, we can consider an abstract composite service as a service composition template, which will significantly reduce the number of alternative composite services to be considered during the service composition process. Instead of challenging the validity of any given abstract composite service, the composition process will concentrate on realizing every service category included in the composite service. For this reason, abstract composite services are usually pre-defined (manually defined) and centrally managed by system administrators. Overtime innovative composition solutions may also be discovered and added into our composition framework to expedite the service composition process. Composition level 2 (Business Unit Level): Based on the abstract composite service identified at level one, concrete composite service will be further formulated at this level. Different from level one, in order to address the inherent dynamicity of business applications, service composition algorithms will be explored to dynamically construct a chain of business units with respect to every sub-goal (service category) in the abstract composite service. To facilitate the construction of concrete composite services, a forward chaining algorithm has been designed and developed by us. The details of our algorithm can be found in (Chen et al. 2007) as described in chapter 5. Building on top of a semantic matchmaking tool (Paolucci et al. 2002), which is widely used for automated service discovery and is exploited in this thesis to identify the semantic correspondence between service inputs and service outputs of every business unit, our service 129

147 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework composition algorithm will automatically chain a group of business units together to satisfy the specific requirements of any business sub-goals. The algorithm is highly efficient and scalable. It will be demonstrated through a prototypeing system in section 6.3. Composition level 3 (Web Service Level): In order to construct a business process that works in practice, every business unit of a concrete composite service obtained at composition level two has to be properly instantiated, the result of which is an executable composite service. This is realized through a selection process that associates each business unit with a Web Service that belongs to the unit. Obviously, a single concrete composite service can lead to diverse instantiations or different executable composite services. To determine the eligibility of any instantiation, in the next section, business rules will be introduced for the purpose of modeling and evaluating the preconditions and results of each candidate Web service considered for a business process. Web services that prove to possess high utility to the business process will be selected for instantiating the concrete composite service. The service selection problem can be very complex since the services in the business process may interact with each other in highly sophisticated manner, resulting in capricious outcomes. To tackle this problem, stochastic search strategies based on evolutionary algorithms will be exploited in this research. It is to be noticed that our service composition framework does not exclude other algorithms from being applied to solve the service selection problem at composition level three. Depending on the 130

148 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework application domains, efficient algorithms will be designed in the future to further improve the efficiency and performance of our three-level service composition system. 6.2 Service selection and composition using business rule This section presents the technical details of applying business rules technology to service selection and composition at level three of our hierarchical composition framework as shown in Figure 6.2. The basic idea is to utilize business rules as a general vehicle to drive the modeling and processing of the essential business logic behind every Web Service interface. To be more specific, using one of the recommended rule languages in OWL-S specification SWRL, business rules is utilized to model the preconditions as well as the results of any business service in a domain-dependent and semantic-rich manner. Service composition in general is an enterprise-wide collaborative activity. When a complete composite service across the local administrative boundaries is to be formulated, the technical detail of each component Web Service usually is of minor significance as compared to the high-level service abstractions. In line with this view, our service composition framework will work primarily with Service Profiles. Two aspects of service behavior described in OWL-S are of particular interests to services composition: (1) information processing as embodied by service inputs and outputs, and (2) the state change caused by service invocation in the form of preconditions and results. To be more specific, the exact inputs and outputs of a service will be 131

149 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework semantically marked up with domain ontology. The precondition and result of a service, which capture essentially the background business logic of the service, will be modeled using business rules. At composition level three (Web Service Level) in Figure 6.2, the instantiation of every business unit of a concrete composite service is to be approached in two steps. Function-oriented service matching will be performed first. That is, given any business unit BU of the concrete composite service, a set of Web services belonging to BU will be identified. Among this set, in order to determine which Web service is the most suitable choice for a business process, a utility-oriented service selection process will be further performed. In the following subsections, we will explain in detail the concept of service utility at both local and global levels, the evaluation of utilities, as well as the exploitation of the evaluation results through a GA-based service selection algorithm Definition of Service Utility For any service in a prescribed business environment, regardless of whether it is atomic or composite, its utility to every business activity conducted in the environment can be examined through a series of n features. For example, one feature would represent the money cost of using the service whereas another feature might be used to indicate the total processing time for handling each of its requests. For easy analysis and calculation, we assume that each feature can be quantified through a real value. Notice that the real value of a feature is closely 132

150 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework related to the service under consideration. Different service might possess different values for all its features. To make this distinction clear, is used to denote the value of feature with respect to a certain service. Obviously it is possible that, if. Every feature is associated with a real-valued weight that satisfies the equation below Using the weights thus defined, the utility of a service can be therefore evaluated as If a service considered is atomic (i.e. represents an atomic web service), its utility will be termed local utility to distinguish from the utility of a composite service, which will be called the global utility. In this section, we focus primarily on executable composite services that are instantiated from a concrete composite service CCS, denoted as. All elements of are atomic services. Due to the conceptual differences between atomic and composite services, the evaluation of their features and utilities is also significantly differed. In short, the feature and utility of an atomic service will be evaluated based on the precondition and result of the service, which are modeled through business rules. The evaluation of 133

151 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework the feature and utility of a composite service, on the other hand, depends on the features of each of its component service. Meanwhile, the customer request to be satisfied through a composite service also has a strong influence on its utility, as explained in subsequent subsections. As a summary of the above descriptions, the ultimate goal for service selection and composition at composition level three (Web Service Level) can be modeled simply through the equation below. In another word, among all possible instantiations of a concrete composition service CSS, we are trying to identify the one that maximizes the utility Business rules enhanced service description The calculation of service utility presented above requires evaluating the value of a set of features. For any given service and feature, could vary significantly depending on the structure of the composite service that contains and the user requirement. For example, for a monitor supply service, the unit price of monitor products varies with the amount of monitors user orders. The more products you buy the cheaper price you will get. This is a real world business practice. Moreover, the execution context may also affect the features and utility of a service, especially when the result of current service execution is influenced by the service that follows. As an example, the cost and the shipping time of a shipping service will rely on both the preceding supplier service and succeeding consumer service. The locations of the two 134

152 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework services and their geographical distance can only be determined during the process of service composition. In order to model the dynamicity of service utility, service descriptions will be enhanced with business rules. Business rules serve as a powerful and important tool in describing the operations, definitions and constraints that apply to an organization. A business rule is comprised of two parts, namely, the antecedent and the consequent. The antecedent governs the conditions for the corresponding rule to become satisfactory. It usually assumes the form of a conjunction of atomic conditions. When all these atomic conditions are satisfied, the consequent as defined in the rule will take effect. Business rules can be applied to model both the preconditions and the results of a Web Service. In case a rule is used to model the preconditions. The antecedent of the rule specifies the situations for the service to become accessible. For example, with respect to a service that handles product orders, a plausible precondition would be that the client s bank account must be valid. On the other hand, when modeling service results, business rules can be used to represent related but different results after calling the service. For example, we can use a business rule to model the simple fact that when a product is purchased, $100 will be deducted from the client s bank account. In our service composition framework, Semantic Web Rule Language (SWRL) (Horrocks et al. 2004) is utilized for writing business rules. SWRL is an emerging 135

153 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework standard rooted in OWL, a popular ontology language based on the RDF (Klyne and Carroll, 2004). Through extending the set of OWL axioms, Horn-like SWRL rules can be designed to manipulate OWL classes and properties, and to infer new knowledge from existing OWL knowledge bases. SWRL also provides a range of build-ins to support various mathematical and logical calculations. A complete specification for SWRL can be found in (Horrocks et al. 2004). Next, we will illustrate the use of SWRL through a simple example. Suppose we want to model one potential effect of a service that sells PC monitors and cost is one of service features. Using natural English, this effect can be described with rule R1 below. R1. IF (C1) the monitor size is 17 inch; and (C2) the quantity of monitors to be purchased (?q) is less than 500; THEN the total service cost incurred is (?qx256) dollars. The antecedent of rule R1 contains two conditions C1 and C2. Assume that a client issues a request to this service for purchasing twenty 17-inch monitors. This request satisfies both conditions C1 and C2. According to R1, when the service call is finished successfully, (20X256) dollars will be deducted from the client s bank account. This result is reflected through the change of total service cost contained in the OWL knowledge base (Ref subsection 6.2.3). In order to specify R1 using SWRL, a proper group of OWL ontologies is to be defined. In the context of R1, two ontology concepts can be identified, namely, 136

154 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework Monitor and Service cost. These two concepts are implemented via OWL classes. For the Monitor class, it contains two properties: monitorsize and quantity. Meanwhile, we can create another property, namely cost, for the Service cost class. Based on the identified OWL classes and properties, the SWRL description for rule R1 is presented in Figure 6.3. Figure 6.3 SWRL description for rule R1 As shown in Figure 6.3, seven atomic conditions are involved in defining the antecedent of R1. They are linked together using the conjunction relation. It is easy to verify that the first three atomic conditions realize condition C2. The fourth and the fifth atomic conditions together realize condition C1. The build-in command swrlb:multiply is utilized in the sixth atomic condition to calculate the total service cost. Finally, the calculated cost is used to update the cost property of Service cost in the consequent of R Local Utility evaluation The evaluation of local utilities is achieved through examining the preconditions and results of each candidate web service considered for a concrete composite service. Upon evaluating a concrete composite service, an OWL knowledge base will be 137

155 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework initialized with the business request from the clients (modeled as OWL classes), which is expected to be satisfied through the instantiations of concrete composite services. The knowledge base is a pool of information regarding the business goal and the overall service execution environment. It is termed a knowledge base since the information it contains is described through semantic structures. To facilitate the evaluation of the utility of any Web services, when a service is considered for instantiating a concrete composite service, the expected results of all of its prerequisites will be made available in the knowledge base. A procedure that meets this requirement is given in Figure 6.5. Driven by the OWL knowledge base, local utility can be calculated through evaluating the preconditions and results of each candidate Web service. The detailed procedure is shown in Figure 6.4. Please note that evaluating these rules may result in modifications of the OWL knowledge base that serves as the local execution context. The impact of candidate services to the whole business process can be achieved therefore through the modified knowledge base. As a result, each time when a new instantiation of a concrete composite service is evaluated, a clean OWL knowledge base should be created to eliminate the possible impact from the services considered previously. 138

156 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework Figure 6.4 Local utility evaluation Global Utility evaluation Upon given an executable composite service, the evaluation of its utility (i.e. global utility) will be approached as shown in Figure 6.5. To calculate the global utility of, the first thing to do is to find out the values of all features associated with, namely evaluating. After that, the definition of utility in subsection can be applied directly to determine the utility of. Since is an integration of multiple atomic web services. For any to be calculated, it can be therefore modeled as a function below Depending on the application domains and the exact features considered, the above function can take a variety of forms. Without restricting the type of features supported, 139

157 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework our service composition system allows users to control the assessment of each feature through business rules, similar with the rules explored to model the precondition and result of each web service. In another word, users can specify how function is to be calculated using the business rules as a universal modeling language. In the next section, two important features, namely the total money cost and the total processing time, will be utilized to drive the selection and composition of Web services in a PC manufacturing CVE. To determine the values of the two features for any composite service, two simple rules as shown below will be utilized: R2. If the money cost of every component Web service is available in the OWL knowledge base, then the money cost of is obtained simply as a summation of the cost of each. R3. If the processing time of every component Web service is available in the OWL knowledge base, then the processing time of is determined as the maximum completion time of any. The completion time of a service is defined recursively as the maximum completion time of any of it prerequisites plus the processing time of service itself. To use the above two rules, we must know a priori the money cost and processing time of every component Web service. This is achieved through evaluating the business rules associated with the preconditions and results of these services. To make sure that the business rules evaluation will be performed correctly, it is 140

158 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework necessary to ensure that whenever a service is to be evaluated, either of the two conditions must be satisfied. C1. The service has no prerequisites in. C2. All prerequisites of in have been evaluated previously. Meanwhile it is also important to evaluate each exactly once before calculating the utility of. After assessing each component Web service of the composite service according to the two conditions C1 and C2, eventually the value of every feature of can be identified. The utility of is determined accordingly Service Selection Algorithm Figure 6.5 Global utility evaluation In the previous subsection, a procedure for evaluating the global utility of an executable composite service has been introduced. Among all the executable 141

159 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework composite services that can be possibly instantiated from a given concrete composite service, we need to identify at least one with relatively high utilities. To achieve this objective, a service selection algorithm based on GA has been designed and presented in Figure 6.6. The algorithm is a direct application of GA to service selection problems. For detailed information of GA, please refer to (Goldberg, 1989). 1. Generate initial population of n Executable Composite Services based on a Concrete Composite Service by repeating n times of following step: a) Random select Atomic services for the Concrete Composite Service to form an Executable Composite Service (instantiation) 2. Evaluate the population by passing n Executable Composite Services to Business Rule Evaluator which will calculate the local & global utility of each Executable Composite Service. 3. Create a new population by repeating following steps until the new population is complete a) Rank the population according to their global utilities and select two Executable Composite Services from the population based on their ranking b) Crossover (one point) the two selected Executable Composite Service to form two new Executable Composite Services with a crossover rate c) With a mutation rate mutate new Executable Composite Services d) Place new Executable Composite Services in a new population 4. Replace the old population with new generated population for a further selection 5. If the user requirement is satisfied, then stop and return the Executable Composite Service with the highest global utility in current population 6. Else go to step 2 Figure 6.6 A service selection algorithm for constructing composite services with high global utilities 142

160 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework The purpose of the selection algorithm is to demonstrate that business rules and consequently the utility associated with each Web service can be effectively explored to guide the formation of business processes that will eventually meet the business goals of a CVE. However, we are not excluding the possibilities of using other more efficient algorithms for optimizing the global utilities, exploiting perhaps the particular structures of composite services as well as the application domains. For this reason, in the experiment study of next section, the efficiency of the selection algorithm will not be investigated in depth. Instead, it will be shown that, using our selection algorithm, executable composite services with near-optimal utilities can be identified after a few generations of stochastic search. 6.3 System prototyping and experiment A prototypeing service composition system has been developed as a demonstration of our rule-enhanced service composition framework proposed in the previous two sections. The system is applied to a PC manufacturing CVE, which is one of the primary application themes considered by our local industrial partners in Singapore. The effectiveness of the system has also been experimentally evaluated. The results confirm with our claims and discussions presented so far. Some results that clearly illustrate the point will be reported at the end of this section Scenario With new material and technology emerging, computer products upgrade frequently. In this ever-changing environment, business processes for PC manufacturing need to 143

161 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework be dynamically formulated, configured and executed in order to respond to the dynamic market demand (Swamidass, 2002). In addition, to achieve significant cost savings, most of computer manufacturers increasingly concentrate on their core competencies and outsource other functions to third parties (Foster et al. 2002), such as product design function and casing manufacturing, etc. In order to fulfill market demand for computers, a timely alliance of enterprises will be formed to share their functionalities and resources in a collaborative manner. As shown in Figure 6.7, company A, B, C and many others join together to formulate a Collaborative PC manufacturing Virtual Enterprise. From the functional perspective, our CVE system aims at automating the manufacturing process after receiving customers' requests. Its proper operation relies essentially on the collaboration of various business functionalities (e.g. product engineering, material purchasing, manufacturing and shipping, etc) as shown in Figure 6.1. The collaboration of these functionalities forms an abstract composite service at the composition level one (Service Category Level). 144

162 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework Figure 6.7 Partial view of a PC Manufacturing CVE (also viewed as a concrete composite service) Each of the functionality in Figure 6.1 is a high-level abstraction of a series of service categories. We use a composite service chainer based on the forward chaining algorithm to identify a group of business units that together form the concrete composite service at composition level two (Business Unit Level, Ref. Section 6.1). The chainer relies on the semantic markup of service inputs and service outputs associated with every business unit. For example, to realize the Product Manufacturing function at level one (Service Category Level) in Figure 6.1, a group of business units, including Adaptor Manufacturing, Casing Manufacturing, PCB Manufacturing, Mother Board Manufacturing and Computer Assembly, etc, will be chained together to establish the 145

163 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework path from initial customer requests to manufactured main units. The details can be found in Figure 6.7 (business units in a green rectangle). In addition to Product Manufacturing, the forward-chaining algorithm will also be applied to other abstract functions such as Material Purchasing at level one (Service Category Level). When this process finishes, the complete PC manufacturing CVE that links suppliers, manufactures, and distributors as a whole will be formed (depicted in Figure 6.7). In order to select the executable composite service with the highest global utility, each business unit in the concrete composite service obtained at composition level two (Business Unit Level) must be instantiated by a Web service with compatible service inputs and outputs. To determine the eligibility of choosing any Web Service to instantiate a specific business unit, the Business Rule evaluation process introduced in section 6.2 will be performed at composition level three (Web Service Level) to evaluate the preconditions and results of this service within the context of the concrete composite service. Only the Web Service that produces the highest utility will be selected to generate the executable composite service. As an example, suppose that two Monitor Supply Web services W1 and W2 (Ref. Figure 6.7) are available for selection in a given concrete composite service. The business rules that govern the respective money cost (considered as service results) of the two services are summarized through a decision table in Table 6.1. The headers of the table jointly specify the antecedents of these business rules, while each cell in the table further indicates the cost to be incurred when the corresponding antecedent is 146

164 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework satisfied. For instance, the upper-left cell stipulates that when the monitor's demand quantity is less than 500, the unit price of 17-inch monitors to be charged by service W1 will be 256 dollars. Obviously, when this antecedent is valid, service W1 will stand for a better choice than service W2. Table 6.1 Monitor Price of Services W1 and W2 Quantity Monitor (Cost S$) < 500 >= 500 W 1 W 2 W 1 W 2 Monitor Size (inch) System Prototyping The prototypeing service composition system has been designed and implemented using Java and Eclipse technology < All Web Services were developed using Apache AXIS2 and deployed on Apache Tomcat application servers. Domain ontology, semantic service description and business rules were created using Protégé-OWL with SWRL Tab (for editing business rule) and OWLS Tab (for editing OWL-S service descriptions). Figure 6.8 shows the architecture of the service composition system. It consists of six main components: 1) 147

165 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework graphic user interface, 2) composite service chainer, 3) business rule evaluator; 4) service composition controller, 5) service repository and 6) OWL knowledge base. The GUI is implemented to support end users in a user-friendly and intuitive manner, accepting manufacturing requests and finally displaying the corresponding service composition results. The OWL-S service descriptions and the associated business rules for modeling the preconditions and results of these services are stored in the Service Repository. Service composition controller is responsible for searching executable composite services that will increase the utilities of using these services to the global optimum. The service selection algorithm shown in Figure 6.6 describes the main operations performed by the controller. The controller is also responsible for parsing user s inputs to OWL models and put them into the OWL knowledge base for subsequent use. It manages the overall formation of a business process by coordinating the operations of other components. In particular, after examining the validity of any user s request, the controller will send the request to composite service chainer to generate a concrete composite service that can possibly satisfy the request. It will also use business rules evaluator to evaluate the associated business rules and calculate the global utilities of any instantiation of the concrete composite service. Composite Service Chainer is implemented based on a forward-chaining algorithm (Norvig, 1991). It is responsible for concretizing every business sub-goal enclosed in an abstract composite service into a chain of business units. The final output of using 148

166 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework this algorithm is a concrete composition service, which will be further instantiated (by the service composition controller) to produce an executable business process. The forward-chaining algorithm can be described as an iterative process. During every iteration, driven by the users requests, a set of candidate business units will be identified and integrated into a partially-formed composite service. The iteration goes on until the users requests have been satisfied, namely one or several business units included in the composite service can produce desirable outputs as requested by users. At this stage, the chaining process is considered complete. After some modifications to trim those unnecessary business units, a concrete composition service is thus formed. The whole process is facilitated by a semantic matching tool that works according to the PC manufacturing ontologies created by us. The open source reasoner for OWL ontology Pellet < is used to perform semantic reasoning. 149

167 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework Figure 6.8 System Architecture Business Rule Evaluator is used to evaluate the local and global utilities of any given service according to its type (i.e. atomic service or composite service). Both the processes in Figure 6.4 and Figure 6.5 have been implemented in this component. Since the business rules employed to model the precondition and result of any service is defined using SWRL, Protégé-OWL (Protege with SWRL Tab is utilized for editing these rules. Additionally, a SWRL Rule Engine Bridge bundled with the Protégé distribution has been exploit in the business rule evaluator to convert SWRL rules to Lisp-like rules so that they can be properly processed by the Jess Rules Engine < 150

168 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework Figure 6.9 User Request Figure 6.9 shows the screen shot of a user manufacturing request where end user can input detailed requests such as the monitor size, processor clock rate, manufacturing quantity, request delivery date, budged upper limit, etc. The various combinations of the request information make it a real world business scenario. After parsing the request input, the service composition controller in Figure 6.8 will instruct the composite service chainer to create a concrete composite service. It also manages the selection of Web services for each business unit in the concrete composite service. Throughout the composite process, the rule evaluator will be frequently utilized to calculate the value of service features. For example, suppose the monitor's demand quantity is less than 500 and there are two monitor supply services W1 and W2 as 151

169 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework shown in Table 6.1. If user chooses to buy 17-inch monitors, service W1 has more probability to be selected because the unit price of 17-inch monitors offered by service W1 (256 dollars) is cheaper than that of service W2 (260 dollars). However, if user requests 19-inch monitors, service W2 stand for a better choice than service W1 as the unit price is 5 dollars cheaper than its competitor. Figure 6.10 shows the screen shot of service composition result which is an instantiation of the concrete composite service as shown in Figure 6.7. Diverse atomic services located in different places have been selected to fulfill a PC manufacture order. The result lists the services chosen for the business process, the prerequisites of using each service, as well as the cost, processing time and the geographical location of these services. For example, the Casing Manufacture service in Figure 6.10 is based in Taiwan, whereas a Mother Board Manufacture service from New York and a PCB Manufacture service from Singapore have also been employed to fulfill the manufacturing order Service Selection Experimentation Experiments have been conducted in an attempt to evaluate the effectiveness of the proposed service selection approach. The concrete composite service used in our experiments includes six business units which directly related to the PC manufacturing. Each business unit has five candidate Web services. So totally we have thirty Web services. The search algorithm uses one point crossover, rank based 152

170 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework selection, and the initial population is randomly generated. Finally, the key parameters of the algorithm follow the settings below: Figure 6.10 Executable composite service details Population_ Size = 50 Crossover_ rate = 0.7 Mutation_ rate = 0.1 Maximum_ number_ of_ Generation =

171 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework As indicated in Figure 6.11, the global utilities of the composite services identified by our service selection algorithm in Figure 6.6 are under 86% of the global optimum in the first several generations. Nevertheless, the utility will be quickly increased to about 95% of the global optimum after only 8 generations of service selection and search. When the 13th generation is being processed, in average 98% of the global optimum can be achieved. After that, the search process stabilizes and eventually converges to a population of composite services with near-optimal global utilities (between 98% and 100% of the global optimum). Table 6.2 shows the change of the global utilities upon using our service selection algorithm. Both the global utility measured in percentage of the optimum and its variations at several representative generations are provided. Percentage of Optimum % Number of Generations Figure 6.11 Search performance 154

172 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework Table 6.2 Percentage of optimum and Variation Number of generations Percentage of optimum % Variation E E E E E E E E E E E E

173 Chapter 6: Business Rule Enhanced Semantic Service Composition Framework 6.4 Summary In order to systematically address semantic web service composition, a business rule enhanced semantic service composition framework is further presented and analyzed in this chapter. We adopt the divide-and-conquer strategy and propose a hierarchical composition architecture to handle tasks of complex service composition. By structuring the overall composition process into three semantically distinct levels, the inherent complexity of forging a composite service will be effectively managed and controlled. Suitable technologies for separate composition levels have been discussed with special emphasis on applying business rules to service description and selection. In this framework, the description of each Web Service is enhanced with rule-based modeling of the essential business logic behind the service interface. A formal notion of service utilities has been provided. Complete processes for calculating the service utilities have also been introduced through processing and evaluating these business rules. A PC manufacturing CVE derived from a practical industrial setting is designed and a prototypeing system is developed to experimentally evaluate the effectiveness of our service composition framework. 156

174 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services 7 Dynamic Self-healing for Composite Service with Semantic Web Services With the increasing complexity of composite services in an efficient new business paradigm CVE, self-healing capability is becoming an important issue in order to support robust composite service execution. In this chapter, to achieve dynamic selfhealing for composite services, a self-healing capable composite service execution system is proposed. The execution system takes advantage of the complementary strengths of OWL-S and BPEL in the following ways: (1) a dynamic self-healing mechanism is proposed which can dynamically identify suitable alternatives and replace faulty services such that a composite service can be performed successfully despite of unexpected exceptions; (2) an OWL-S process to BPEL process Mapper is presented which can translate OWL-S process to BPEL process and meanwhile embed the self-healing mechanism into BPEL workflow. Semantic Web service technology plays its part for service matching and selection during the self-healing process in a sense that Semantic Web services are equipped with rich business rules in a domain-dependent manner. A concrete scenario PC manufacturing CVE is used to demonstrate the effectiveness of self-healing capable composite service execution system. 157

175 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services This chapter first introduces the concepts for self-healing in section 7.1, a self-healing capable composite service execution system is presented in section 7.2, followed by self-healing mechanism in section 7.3 and an OWL-S process to BPEL process Mapper in section 7.4. Finally, section 7.5 summarizes the chapter. 7.1 Concept for self-healing In a practical industrial setting, the effective and efficient service composition is often not sufficient for dynamic natures of CVE. With increasing number of organizations expose their business functions as Web Services and increasing complexity of business processes, the dynamics in real application context when addressing the service composition very much complicate the matter. And it is often desirable to accomplish composition with high degree of serviceability, especially when environment changes or when services previously used becomes unavailable. A composite service for a business goal must be able to address many such kind of dynamic changing issues with less or no external interventions, and in this case selfhealing capability of a composite service has appeared as an attractive approach. A self-healing system must be able to perceive that the system is not operating correctly and make the necessary corrections to restore itself to normal operation without human intervention. It denotes the system has the ability to detect, diagnose and react to system malfunctions to prevent disruptions. To achieve self-healing, a system must have knowledge about itself and its environment, such as current status of its components, available resources and connections with other systems (Horn, 158

176 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services 2001). In this research, self-healing refers to a capability of a composite service to maintain its serviceability by healing itself when its component service becomes unavailable. 7.2 Self-healing capable composite service execution system Target at fully supporting flexible service composition and robust composite service execution in CVE, we propose a self-healing capable composite service execution system which has following features: (1) in order to offset each other's weakness, we make an attempt to combine the complementary strengths of OWL-S and BPEL. On the one hand, having semantic support, OWL-S is used in dynamic service discovery and composition at high level. On the other hand, industry-based BPEL is exploited in service execution at concrete level; (2) in addition to modeling service inputs and outputs using semantics, service descriptions are further enhanced with business rules that capture the underlying business logic behind the service interfaces as described in chapter 6; (3) a dynamic self-healing mechanism is proposed, which can dynamically identify suitable alternatives and replace faulty services such that a service flow can be performed successfully despite of unexpected exceptions. This mechanism explicitly utilizes Semantic Web services for service matching and selection of a composite 159

177 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services service in composite service. We explore the self-healing mechanism for supporting self-healable composite service execution which is modeled in BPEL4WS; (4) OWL2BPEL Mapper is further proposed to translate OWL-S process to BPEL process by converting data, data flow and control flow into BPEL counterparts, and embed the self-healing mechanism into BPEL process. It bridges the gap between OWL-S and BPEL and maintains the semantic information during their interoperation System architecture Our comparison studied in chapter 5 shows that BPEL approach is lack of flexibility and dynamicity in service discovery and composition, while OWL-S approach is right to solve the problem due to its semantic-rich description. In line with this view, we adopt OWL-S as the composition strategy at high level by taking advantage of its flexibility and dynamicity in service composition. The inputs and outputs of a service will be marked up with domain ontologies. In addition, service descriptions will be further enhanced with business rules that are utilized to model the preconditions as well as the results of any business service. The execution system will take different actions to fulfill the composite service according to correspondent preconditions/results which subsequently influence the composite service execution. Through processing these business rules in the context of any given composite service, our execution system makes decisions at functional level to increase responsiveness to customers and facilitate the robustness of composite service. 160

178 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services Although OWL-S has its own strength in composition, it is still in its early stage. The adoption of OWL-S hasn't been prevalent for lack of tools to support the development. Moreover, there is no mechanism designed for OWL-S to identify faults during execution. Nevertheless, BPEL has strong points which can offset OWL-S' weakness. Currently, major vendors successively provide their runtime environment for executing BPEL business processes for both J2EE and.net platform. In addition, BPEL has correspondent process design environment with a graphical user interface such as Oracle JDevelop. Furthermore, BPEL provides systematic mechanisms for dealing with business exceptions. In view of these facts, BPEL is exploited in service execution at concrete level. In order to achieve dynamic self-healing for composite services, a self-healing capable composite service execution system is proposed by taking advantage of the complementary strengths of OWL-S and BPEL. Figure 7.1 shows the architecture of our Composite Service Execution System with self-healing capability. It includes the following components: Service Composer, Self-healing Composite Service Generator (SCSG), BPEL Execution Engine, Service Repository and Knowledge Base. 161

179 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services Figure 7.1 Self-healing capable composite service execution system The Service Composer has already elaborated in chapter 6. Its input is the requested service capability which refers primarily to the required outputs of a service given the available inputs. Its output is an executable composite service with near-optimal global utilities. In the following context, the composite service is referred to the executable composite service which is the output of our hierarchical service composition framework. To achieve rule based service selection in self-healing process, the description of each atomic Semantic Web service is enhanced with local business rules; and the description of each composite service is enhanced with global business rules. The local business rules contain domain specific information suitable for subsequent service selection, such as processing time and money cost as described in chapter 6. Global business rules define a set of selection criteria (i.e. one may favor the service 162

180 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services which has minimum cost, while the other favors minimum processing time) to choose one service among a list of alternatives based on the local business rules evaluation results. Therefore, the global business rule plays a determinant role in service selection. Both local and global business rules are identified by Rule URI which can be referred by their Semantic Web service description. Self-healing Composite Service Generator is comprised of two parts: (1) self-healing mechanism; (2) a OWL-S process to BPEL process mapper. OWLS2BPEL Mapper takes composite service as input and outputs a standard BPEL process without losing semantic information. At the same time, it embeds the self-healing mechanism into BPEL process. Before the BPEL process is deployed into BPEL Execution Engine, business process design tools such as Oracle JDevelop can be used to refine the converted BPEL process. All the services written in WSDL and OWL-S advertised by Service Providers are stored in the Service Repository. In addition to keep the dynamic execution environment, the Knowledge Base also stores the domain ontologies written in OWL which are utilized to mark up IOPR of semantic service as described in chapter Self-healing mechanism and its application in PC manufacturing CVE Today, increasing number of organizations expose their business functions as Web Services. As the use of Web services grows, more and more organizations are 163

181 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services choosing BPEL4WS for modeling business processes within SOA. In order to support robust composite service execution, self-healing in composite service is becoming prominent. In general, self-healing includes faults detection and recovery. BPEL provides a set of standard faults detection and recovery mechanisms, such as Fault handler, Compensation handler, and Event handler which are automatically executed by the BPEL execution engine. However, these basic recovery mechanisms are quite simple and scopes-oriented. The recovery is only to compensate all effects of a faulted scope and to continue the composite service execution without any results obtained from this scope, and do not support sophisticated recovery actions (Modafferi et al. 2006) such as service replacement. Furthermore, the standard recovery mechanisms provided by BPEL language are static in a sense that they are defined in the composite service design phase. In this research, we define the "self-healing composite service" as a composite service which can be locally recovered from the faults detected during its execution. Generally, there are two approaches to self-healing of a composite service: static and dynamic. In a static approach, self-healing is addressed at the design time, that is, for every possible faulty in a composite service, a fault handler is constructed at the design time which specifically handles the anticipated fault. If the fault encountered is not expected during the design of the composite service, the composite service is unable to handle it as there is no predesigned handler available. On the other hand, in a dynamic approach, any fault that occurs at the run time is handled by dynamically constructing, at the run time, a replacement of services which sufficiently matches the 164

182 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services faulty one based on some criteria. In this research, we focus on the dynamic selfhealing mechanism for composite service Self-healing mechanism Our self-healing mechanism aims to replace the faulty service dynamically. It is used to build Self-healing Composite Service Generator which addresses the issue at the two different levels. At high level, having semantic support, OWL-S is used in dynamic service discovery and composition. At the concrete level, industry-based BPEL is exploited in service execution. The Self-healing Composite Service Generator bridges the gap between OWL-S and BPEL. It embeds the self-healing mechanism into BPEL service flow which achieves dynamic Web service replacement. Dynamic Web service replacement during self-healing procedure involves service discovery and selection. To improve the effectiveness of service discovery, we exploit the Semantic Web service technology. The inputs and outputs of a service will be marked with domain ontologies. In addition, to facilitate policy based service selection, the description of each atomic Semantic Web service is enhanced with local business rules which capture the essential business logic behind the service interface; and each composite service is enhanced with global business rules which set the selection criteria for alternative service. A sample of BPEL script generated by Self-healing Composite Service Generator is shown in Figure 7.2. The BPEL fault handlers is used to catch faults and provide 165

183 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services exception handling. In order to deal with exceptional situations more locally to the place where they occurred, the fault handlers can associate with a scope. A scope provides the behavior context for each activity which represents an invocation of a Web service operation. When a fault happens within a scope, a local fault handler can deal with it before the scope s processing ends. Figure 7.2 shows the scoped fault handling. We utilize catchall element instead of catch to house all the error handling activities. This is due to the matching fault handler cannot be found if the operation of a Web service doesn't define the correspondent error messages as its outputs. Figure 7.2 Scoped fault handling Once Fault handler catches a fault, the self-healing mechanism will be started. It is composed of the following major steps as shown in Figure 7.5: 1. Find a list of alternative services 2. Update knowledge base to record the information on matched services 166

184 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services 3. Apply both global and local business rules & update knowledge base & select one service 4. Invoke the selected service The 4-steps self-healing procedure is realized through four well designed Web services. They are Service Discovery, KB Update, Evaluation & Selection, Service invocation. If an error occurs during a service invocation such as the service is currently unavailable, the self-healing mechanism will discover alternative services first given the semantic description of the faulty service as inputs. And their related information e.g. the URL of a service, the URL of local business rules, etc will be updated in the knowledge base. Thereafter, the local business rules of each discovered service will be evaluated. Based on the evaluation results, the global business rule will determine the final service. Last, the selected service will be invoked. The following subsections will give more details on each step of our self-healing mechanism Service discovery In order to find an alternative service to replace the faulty service for self-healing purpose, the Semantic Web service discovery technology is exploited. Based on the service inputs and outputs, we define three matches in our current Service Discovery Web service. While an exact match appears attractive, a various weak form of match may be found serving the purpose. 167

185 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services Definition 1 (Relax-Input-Match): match r input, ( A B) = Ainputs Binputs Service A is said Relax-input-matched with service B if and only if inputs of service A are the superset of inputs of service B. This will guarantee that all the inputs of service B are valid for service A and that service A is a potential replacement for service B. If inputs of service A are the subset of inputs of service B, that means some inputs of service B are not suitable for service A, therefore service A cannot replace service B. Definition 2 (Subsume-Output-Match): match s output, ( A B) = Aoutputs Boutputs Service A is said Subsume-Output-matched with service B if and only if outputs of service A are the subset of outputs of service B. This will guarantee that all the outputs of service A are valid for service B and that service A is a potential replacement for service B. Definition 3 (Relax-IO-Match): match ( A B) = match ( A, B) match ( A B) RIO, r Input s Output, 168

186 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services Service A is said Relax-IO-matched with service B if and only if inputs of service A are the superset of inputs of service B and outputs of service A are the subset of outputs of service B. When the Fault handlers catch a faulty service, its service capability will be served as input of Service Discovery WS. The requested service (the faulty service) will be matched against all the advertisements stored in the service repository. Based on the concept subsumption relations in the corresponding ontology, our Service Discovery WS can determine a list of services that semantically match with the given faulty service. The matching algorithm based on the above definition is shown in Figure 7.3. When there is no exact matched service, the relax matched service can also work. Figure 7.3 Matching algorithm Knowledge base update Knowledge is presented by ontology which is a specification of formally described, machine-readable collection of concepts and their relationships within a domain. The concept of ontology enables description of explicit semantics. In order to record the discovered services for further service selection purpose, the ontology for self-healing 169

187 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services procedure should be built in addition to the domain ontology. During service flow execution, the knowledge base serves as a semantics container to store all the dynamic execution information. Again, we use Web standard-based way OWL-S for representing ontology. Figure 7.4 shows the ontology for self-healing. The two OWL classes, namely, CompositeWS and AtomicWS are subclass of the root class Thing. An instance of CompositeWS will be created for each of the outputs of Service Composer. Global business rules will be associated to each instance of CompositeWS. The faulty service and discovered services are instances of AtomicWS. CompositeWS has one object property hasfaultyservice which has a range class AtomicWS. AtomicWS has one object property hasreplaceableserivce whose domain and range classes are itself. Each class has their correspondent datatype properties, such as service Name, service URL, etc. During the knowledge base updating phase, an instance of the faulty service will be created first followed by each matched service in the matching list. The relationship between the CompositeWS and the faulty AtomicWS, the faulty AtomicWS and matched services are also established accordingly. 170

188 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services Figure 7.4 Ontology for self-healing Rule evaluation and rule driven service selection SWRL is utilized for the local business rules as described in chapter 6. Semantic Query-Enhanced Web Rule Language (SQWRL; pronounced squirrel) (Yuhana, 2007) is utilized for global business rules. SQWRL is a SWRL based query language that can be used to query OWL ontologies. SQWRL provides SQL-like operations to format knowledge retrieved from an OWL ontology. The SQWRLQueryAPI offered by Protégé is used to retrieve the result of SQWRL queries. It provides a JDBC-like Java interface. An SQWRL description can be found in section To our knowledge, the actual use of SWRL in OWL-S specification is to use SWRLbased expression to model precondition and result. It does not support full rule specification. In this research, both local and global business rules are used to purely support service selection. Due to conceptually different from precondition and result 171

189 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services according to OWL-S specification, we put their URL into ServiceParameter of OWL- S profile. Two open-source projects, Protégé and Jess Rules Engine < are exploited in the rule evaluation. Using SQWRL Query Engine bundled with the Protégé distribution, both local and global business rules can be processed by the backend Jess Rules Engine. Based on these tools, we develop the Rule Evaluation WS Service invocation Based on the rules evaluation results and selection criteria, the final service will be selected. Given the selected service URL and the input variable of the faulty service as inputs, the Service Invocation WS will invoke the selected service. The output of the Service Invocation WS is the output of the faulty service. Figure 7.5 shows the self-healing procedure realized by four Web services. The inputs and outputs of each WS are shown in the red rectangle. The generated self-healing composite service which modeled in BPEL is depicted in Figure 7.6. It is a simplified version for illustration purpose. The input and output ontology of the faulty service will be fed into the Service Discovery WS. The Service Discovery WS will perform the semantic matching and return a list of matched service URL. Upon knowledge base update and business rules evaluation, the substitution service will be selected. The selected service URL and the inputs of original faulty service together will be assigned to a new variable which will be subsequently consumed by the Service 172

190 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services Invocation WS. The output will be assigned to the original faulty service output variable which will be served as input of next Web service in the composite service. In such a way, the self-healing procedure merged with the original service flow seamlessly. The abstract part of simplified WSDL description of Service Discovery WS is shown in Figure 7.7. Figure 7.5 Self-healing procedure 173

191 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services Figure 7.6 Generated self-healing service flow 174

192 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services Figure 7.7 WSDL description of Service Discovery WS 175

193 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services Self-healing mechanism in a PC manufacturing CVE In this subsection, we will apply the self-healing mechanism into a concrete manufacturing CVE PC manufacturing CVE to validate its effectiveness. In order to respond to the dynamic market demand for computers, business service flows for PC manufacturing need to be dynamically formulated and executed to share their functionalities and resources in a collaborative manner. Figure 7.8 shows a part of composite service formulated in a PC manufacturing CVE. After processing customer order, a monitor purchase order is issued to the MonitorSupply Web service which produces a delivery order. For computer assembly purpose, HardwareShipping Web service has to ship monitors to the company which can assemble the computers. Our self-healing capable composite service execution system will be evaluated based on this scenario. We will illustrate the self-healing procedure once a fault is caught by the Fault handler due to the MonitorSupply service is currently not available. Figure 7.8 Part of composite service in PC manufacturing CVE Service discovery Suppose the input of MonitorSupply service is LCDMonitorPurchaseOrder and its output is MonitorDeliveryOrder. The input and output represent the service 176

194 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services capability which will be exploited in semantic service discovery. While exact match between services appears to be the best choice, very often, this kind of match cannot be found. In such a case, many flavors of relaxed match may also serve the purpose. For example, as shown in Figure 7.9, if we have an ontology that defines "LCDMonitorPurchaseOrder is-subclass-of MonitorPurchaseOrder", and "LCDMonitorDeliveryOrder is-subclass-of MonitorDeliveryOrder", we may find a list of Web services that serve our needs. For instance, a monitor supply service with MonitorPurchaseOrder as its input and LCDMonitorDeliveryOrder as its output is matched with the faulty MonitorSupply service. Figure 7.9 Partial domain ontology Knowledge base update Next, the searched results will be updated in knowledge base. Suppose we discover two MonitorSupply services from company C1 and company C2 respectively which are both matched with the faulty service. Based on the self-healing ontology designed in Figure 7.4, the services instances are created correspondently in knowledge base as 177

195 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services shown in Figure The PCmanufacturing composite service has a faulty service MonitorSupplyWS which has two replaceable services MonitorSupply_C1 and MonitorSupply_C2. The knowledge base also contains domain ontology. For example, a Monitor class which has properties such as quantity and monitorsize. Figure 7.10 Created instances in knowledge base Rule evaluation and rule driven service selection Each of these replaceable services is associated with local business rules which have already been elaborated in chapter 6. Here, we will show how the evaluation result will be reflected in the knowledge base. Suppose the following business rule models the estimated cost of MonitorSupply_C1 service. Using natural English, this local business rule can be described with rule R1 below. 178

196 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services R1. IF (c1) the monitor size is 17 inch; and (c2) the quantity of monitors to be purchased (?q) is less than 500; THEN the estimated service cost incurred is (?qx250) dollars. The rule R1 contains two conditions c1 and c2. Assume that a client issues a request to this service for purchasing four 17-inch monitors. This request satisfies both conditions c1 and c2. According to R1, if the service call can be finished successfully, the estimated cost will be (4X250) dollars. This result is reflected on the estimated cost property of MonitorSupply_C1 service instance contained in the OWL knowledge base as shown in Figure One prerequisite for specifying R1 using SWRL is to design a proper group of OWL ontologies. In the context of R1, two ontology concepts can be identified, namely, Monitor and MonitorSupply_C1. These two concepts are implemented via OWL classes as shown in Figure For the Monitor class, it contains two properties: monitorsize and quantity. Meanwhile, we can create another property, namely estimated cost, for the MonitorSupply_C1 class. After local business rules evaluation for these two replaceable services MonitorSupply_C1 and MonitorSupply_C2, the results such as the completion time and estimated cost will be updated in the knowledge base as shown in red in Figure

197 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services In order to select one service among the several alternatives, SQWRL is utilized for specifying the selection rules (the global business rules) for alternative service. Using natural English, this global business rule can be described with rule R2 below. R2. Select the substitution service with minimum completion time for MonitorSupply Web service. Based on the identified OWL classes and properties, Figure 7.11 shows the SQWRL description for R2. Seven atomic conditions are involved in defining the antecedent of R2. The first three atomic conditions identify the faulty service MonitorSupplyWS. The fourth atomic condition selects all the replaceable services for MonitorSupplyWS. The fifth, sixth and seventh atomic conditions together identify the properties of the replaceable services such as completion time, estimated cost and URL. The SQWRL query in the consequent of R2 will return a service with minimum completion time based on the local business rules evaluation results. In this scenario, the MonitorSupply_C1 service from company C1 will be selected because it takes 2 days to get the monitors which is faster than the service provided by company C2. 180

198 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services Figure 7.11 SQWRL description for global business rule R Service invocation Finally, the selected MonitorSupply_C1 service URL and its input will be fed into Service Invocation WS and be invoked to replace the faulty MonitorSupplyWS service. The output will be assigned to the output variable of the faulty service which subsequently serves as the input variable of the following Web service. 7.4 OWLS2BPEL Mapper Another important part in the Self-healing Composite Service Generator is an OWLS2BPEL Mapper which can translate OWL-S process to BPEL process by converting data, data flow and control flow into BPEL counterparts. Meanwhile the Mapper embeds the self-healing mechanism into BPEL process as shown in Figure

199 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services Figure 7.12 OWL-S to BPEL Mapper Background In the literature, only few research works directly concentrate on the relation between OWL-S and BPEL. McIlraith (McIlraith and D.Mandell, 2002) and Ren (2007) presents a high level comparison study between them. Liu (2004) presents a one-way mapping from the DAML-S process model to BPEL4WS aiming to allow DAML-S services to be used by non-semantic enabled clients. The author also tries to clarify the differences and similarities between the two models with more focus on common aspect. However, the precondition and result are left out of mapping due to the Boolean expression for condition was missing from the ontology at that time. Meanwhile, the author argues that precondition and result are mainly for service discovery and nothing to do with service execution. As a matter of fact, precondition and effect can also control the workflow execution at concrete level. Our OWLS2BPEL Mapper extends the mapping to preconditions and results by creating a partner for Rule Evaluator Web 182

200 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services Service to check preconditions and results in the BPEL process. Furthermore, SWRL is utilized for writing expression for condition. In work (Aslam et al. 2006), they present a mapping strategy to map BPEL process to OWL-S ontology to overcome the semantic limitation of BPEL. Their work is different from ours in which the mapping order is reversed. Their BPEL to OWL-S mapping tool is an extension to BPEL4WS2OWL-S tool (J. Shen and Yang 2005) to achieve real and more consistent mapping. Unlike our top-down approach, (Mandell and McIlraith, 2003) takes a bottom-up approach to extend BPEL with automatic service discovery and semantic translation. However, their system relies on a DAML-S based Semantic Discovery Service (SDS) to find and invoke potential service partners during the workflow execution. The service composition still relies on predefined BPEL process and therefore it does not support automated service composition. In contrast, we address the issue at two different levels. At high level, we rely on OWL-S to automate service discovery and composition; at the concrete level, we rely on BPEL to automate workflow execution. OWLS2BPEL Mapper bridges the gap between them. In addition, to our knowledge, no mappers mentioned above ever address preconditions and effects mapping and self-healing issue as studied in this research work. 183

201 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services OWL-S composite service to BPEL process Mapper As there exists similarity in the conceptual model of OWL-S and BPEL (Aslam et al. 2006), we seek the mapping from OWL-S to BPEL to achieve dynamic self-healing for composite service. It includes syntactic mapping and semantic mapping. The syntactic mapping focuses on syntactic aspect such as data (IOPR), data flow and control constructs transformation. Due to lack of semantic support in BPEL, the semantic mapping is about how to convert from each Semantic Web service to a BPEL sub-workflow while maintaining the semantic information. The Mapper relies on two Web services. One is Rule Evaluator Web service, the other is KB Update Web service. They will be presented in more details in section Syntactic mapping The syntactic mapping deals with the transformation from OWL-S process model to BPEL process model. It is similar to the work in (Liu et al. 2004; Aslam et al. 2006). The mapping focuses on syntactic aspect involved with, process model mapping such as data (IOPR), data flow and control constructs transformation. 1) Data and Data Flow: Data mapping is primarily involved with the mapping between IOPR of OWL-S and BPEL variables. In OWL-S, Service Grounding grounds the inputs/outputs of OWL-S atomic process to a WSDL message types (wsdlinputmessage/wsdlinputmessagepart) and defines operations 184

202 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services (wsdloperation) for the atomic process as shown in Figure On the other hand, BPEL interacts with WSDL service interface. For example, BPEL uses WSDL message type as variable declarations. Therefore, OWL-S Service Grounding connects BPEL and OWL-S. In order to get correspondent BPEL part, OWL-S Service Grounding is utilized in this mapping. We can map the input as well as output of the OWL-S atomic service to BPEL variables with the WSDL message type specified in the OWL-S Service Grounding. Figure 7.13 OWL-S/WSDL Grounding As for precondition and result, since they are modeled by business rules in this research work, we refer to these rule files by using their URL in ServiceParameter of OWL-S profile as shown in Figure The Business Rule Evaluator Web Service has one input message (URL of rule file) and one output message (a Boolean value). Thus, the URL of rule file (representing precondition/result of an OWL-S atomic service) will be mapped into BPEL 185

203 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services variable first and then the rules will be processed by the Rule Evaluator Web service. Figure 7.14 URL of rule file in ServiceParameter of OWL-S profile The data flow between atomic processes can be described using BPEL <assign> activity combined with <copy>, <from> and <to> elements. <assign> <copy> <from variable="..."> <to variable = "..." > </copy> </assign> 2) Atomic Process: Atomic Process corresponds to a one-step service interaction that expects one message and returns one message in response. In general, Perform construct in 186

204 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services OWL-S is used to perform an atomic process, BPEL has primitive activity <invoke> to perform some operations. As mentioned above, the values of porttype and operation of the correspondent Web service specified in the OWL-S Service Grounding can be used by the Mapper in BPEL <invoke > activity. If the atomic process has inputs and/or outputs, <receive> and <reply> primitive activity in BPEL are used to receive input messages and/or send output messages from/to some other Web services. The mapping from OWL-S atomic process to BPEL process could be: <sequence> <receive.../> <invoke inputvariable = "..." outputvariable = "..." operation="..." porttype=" " /> <reply /> </sequence> 3) Composite Process: An OWL-S composite process is composed of non-composite or composite processes. Control constructs in OWL-S composite process has similar logic behavior to BPEL structured activities. Figure 7.15 gives a summary of control constructs mapping between OWL-S and BPEL. 187

205 Chapter 7: Dynamic Self-healing for Composite Service with Semantic Web Services Figure 7.15 Control constructs mapping OWL-S Sequence control construct can be mapped to BPEL <sequence> activity to define a collection of activities to be performed sequentially in lexical order. <sequence> <!--- activities ---> </sequence> OWL-S If-Then-Else control construct can be mapped to BPEL <if> activity. The if condition can mapped to a BPEL Boolean typed variable. If the condition holds true, the contained activity is performed. <if> <condition> boolean-expression </condition> <!--- activity ---> <else> <!--- activity ---> </else> </if> OWL-S RepeatWhile control constructs can be mapped to BPEL <while> activity. If the Boolean <condition> evaluates to true at the beginning of each 188