Towards semantically-assisted design of collaborative business

Download PDF
0 downloads 0 Views 284KB Size Report
Comment
Andreas Friesen and Asma Alazeib are with SAP Research, Vincenz-. Prießnitz-Str. 1 .... 3.to semantically assist manual process composition through the ...
Towards semantically-assisted design of collaborative business processes in EAI scenarios A. Alazeib, A. Balogh, M. Bauer, A. Bouras, A. Friesen, P. Gouvas, G. Mentzas, A. Pace,

Abstract — This paper describes two approaches for semantically-assisted design of collaborative business processes in intra- and inter-enterprise application integration scenarios. Both approaches rely on the ENterprise Integration Ontology (ENIO) that resolves structural heterogeneities of different business applications on the data and functional level. Additionally, the ENIO ontology provides a process facet that supports semanticallyassisted creation and adaptation of process templates within a hierarchy of business process categories. Especially for SMEs, the proposed solution should provide additional value, since the achieved degree of automation is expected to reduce the integration costs significantly.

I. INTRODUCTION In the mid-1990s, a new term called enterprise application integration (EAI) was established, which introduced several methods and software components for efficiently integrating software in an enterprise [1]. Since then available enterprise application integration software address integration problems for example in the following ways: a) graphically supporting the mapping of systems’ interfaces to each other (e.g. SAP NetWeaver Exchange Infrastructure), b) reducing complexity using intermediate data-exchange languages (e.g. Extensible Markup Language (XML)) or c) reducing the number of connection adapters needed through the introduction of hubs (e.g. Enterprise Bus). These efforts entail significant costs and typically due to the “lack of automated support in defining integration, it takes a long time for a human engineer to define semantically correct integration.” [2] In literature intra- and inter-enterprise application integration is distinguished, even though most of the same methods and patterns are applied [4]. Manuscript received January 15th 2007. (The paper submitted for review January 15, 2007.) This work was supported in part by the EU Project FUSION (www.fusionweb.org). Andreas Friesen and Asma Alazeib are with SAP Research, VincenzPrießnitz-Str. 1, 76131 Karlsruhe, Germany ([email protected], asma.alazeib@ sap.com). Markus Bauer, Albina Pace, and Andras Balogh are with CAS Software, Wilhelm-Schickard-Str. 10 - 12, 76131 Karlsruhe, Germany (e-mail: [email protected], [email protected], [email protected]). Gregoris Mentzas, Panagiotis Gouvas and Athanasios Bouras are with Institute of Communication and Computer Systems, 9, Iroon Polytechniou str., 157 80 Zografou, Athens, Greece ([email protected], [email protected], [email protected]).

Intra-enterprise application integration (i.e. EAI) is the unrestricted sharing of data and business processes among any connected applications and data sources in the enterprise [3]. Accordingly, inter-enterprise application integration, also called B2B application integration, is the integration of systems between organizations to support any business requirements, such as sharing of information [5]. This strict differentiation is not necessary in this paper, since the automation of integration approaches should cover both areas. For this reason, in the following only the term EAI is used and should be understood as both EAI and B2B application integration. Today companies consume enormous resources for the purpose of software integration to enable the interaction between previously separate enterprise systems. On average 40 % of a firm’s business information processing budget represent integration costs [6]. Companies and the research community agree on the fact that time and effort needed for integration of corporate-wide (standard) applications (like Enterprise Resource Planning (ERP) or Customer Relationship Management (CRM)) is already unsatisfactorily large [1]. Integration efforts are expected to grow in the future due to several reasons, amongst these reasons is the large number of incompatible systems or computer systems, which are connected point to point (also referred to as “spaghetti systems” [6]) in companies, and the internal and external merging and acquisition of companies [7]. Consequently, the goal of this paper is to provide an approach in order to automate the enormous efforts put into manual EAI. This should be achieved by leveraging two additional trends in the computer science community: Semantically-enabled Service oriented Architecture (SESOA) and (semi-) automatic Web Service composition approaches. Most providers of standard software for enterprises (e.g. SAP, Oracle) are currently introducing software that is based on SOA principles to allow for a better reuse of existing software components and to meet customer requirements for a more flexible and adaptable software design. The most-often used low level building blocks of SOA, the so called Web Services, are also seen as a means

to reduce the integration effort [8]. Although novel technologies have been introduced and existing ones have been adapted (e.g. .Net or Java 2 Platform - Enterprise Edition (J2EE)) for building new Web Services, most enterprise Web Services are not created from scratch, but are “cut” from existing applications [9]. Thus, Web Services establish new interfaces to enterprise software, which can be used to bridge the gap between previously unsuitable approaches (i.e. due to proprietary standards). In particular the research area of (semi-)automatic Web Service composition, which basically allows for the automatic combination of multiple Web Services to fulfil a task, seems promising in the context of EAI automation (e.g. [10]). Although Web Services provide novel technologies that enable the automation of EAI and enable interoperability between applications, the technical and functional descriptions are based on non-formal syntactical descriptions that cannot be interpreted by computers, and which require a lot of human intervention. Therefore research efforts in the last years developed socalled Semantic Web Service (SWS) Frameworks, which aims at the semantic annotation (semantic mark-up) of Web Services represented as service profiles, which can be processed by machines. This is achieved by describing the functional behaviour and capabilities of Web Services including the input, output, precondition, effect and quality of service descriptions. SWS Frameworks like OWL-S [20], WSMO [21], SWSF [22] and WSDL-S [23] allow for the automation of: 1. Web Service discovery; automatic discovery of services that provide a given functionality according to the functional descriptions (goal query) provided by a service requester. 2. Web Service composition; a combination of several services in order to provide a required functionality that a single Web Service is not able to provide. 3. Web Service invocation; automatic execution of a Web Service. 4. Web Service interoperation within an enterprise or amongst several enterprises.[19] Five dimensions have been identified in [11] [4] that classify EAI approaches, namely; a) Data-oriented (e.g. extracting information from a database and updating it in another), b) Portal-oriented (e.g. consolidation of distributed data sources in one portal), c) Application interface-oriented (e.g. solutions based on Java’s RMI or CORBA), d) Method-oriented (e.g. methods for the creation of a new customer record in separate finance and distribution systems in a single step), and e) Process Integration-oriented (e.g. integration of an order-to-cash

process across multiple separate systems). The approach proposed in this work has a strong process focus, i.e., it assumes that the systems to be integrated realize specific parts of a collaborative business process representing the integration goal. The executable orchestration of those process parts implements the collaborative business process and therefore fulfils the integration goal. In particular, our approach assumes that the data transformation between the involved systems is possible and is already performed (i.e. the mapping between different data structures in the message exchange). Furthermore, the existence of Web Services representing the interfaces to the functionality of the process parts running in the participating systems is required. The above mentioned assumptions are not very restrictive, since the Web Services can also be newlycreated on top of existing applications and without any compatibility on the data and functional level, an integrated solution cannot be achieved anyway. In order to ensure compatibility on the data and functional levels, we rely on the ENterprise Integration Ontology (ENIO) introduced in the following section. II. ENTERPRISE INTEGRATION ONTOLOGY A. Purpose and structure of the ontology In order to provide formal specification and analysis of EAI scenarios, the data, services and processes that exist within an application integration scenario should be formally and explicitly defined. The ENterprise Application Integration Ontology (ENIO) represents an explicit specification of the conceptualization of the EAI domain [26]. It structures and formalizes the procedural and operative knowledge needed to describe and resolve interoperability problems of EAI. The ENIO Ontology has a four-fold focus: 1. to resolve most message level heterogeneities through the formal definition of the data(-types) in the input and output messages of a service, providing a common reference model of data semantics; 2. to enable effective search and discovery of services through the formal representation of the capabilities and the functionality of the service operators, providing a well structured taxonomy of functional semantics; 3. to semantically assist manual process composition through the definition of a commonly-agreed vocabulary of intended functionality of enterprise services, which ensures the usage of the proper services in a (reusable) process template instantiation with regard to the desired functionality

4. to support semi-automated process composition, providing means intended to be used for the annotation of the interior, behavioural models of complex services, and for the definition of the composition goals of a collaborative business process. The above-mentioned goals of ENIO constitute the basis for the identification of the required dimensions and the composition of the overall structure of the ontology. The ENIO introduces a model of an upper ontology, which covers generic and domain-independent concepts, with several, domain-related extensions called facets. These facets capture data, functional and process semantics of business applications. ENIO is a multi-layered ontology consisting of four layers. The first layer constitutes an Upper EAI Ontology, which is a foundational ontology based on the alignment of DOLCE and SUMO foundational ontologies. The second layer extends the first and covers domain specific concepts, the third layer extends the second and first layer and introduces vendor specific concepts, which inherit concepts from the domain specific layer and finally the fourth layer, which is use case specific, represents instances of the third layer of the ENIO.

Figure 1: The ENIO Conceptual Structure

Figure 1 illustrates the conceptual structure of the ENIO; the Upper EAI Ontology, the domain-dependent (meta-model) and the domain dependent model layers. B. Data Facet The Data facet addresses the problem of data interoperability by enabling the seamless sharing of data among applications in an EAI scenario. Data should be available among applications in a way that is reusable and understandable to systems. It is necessary to provide meaning to data in order to ensure the correct exchange and mapping of data from one application to another. ENIO is designed, first of all, to have significant contribution concerning the resolution of message level heterogeneities in the frame of enterprise process composition scenarios. The Data Facet of ENIO formally

captures the data of the messages exchanged among collaborative enterprise applications that expose their functionality utilizing Web Service technologies. The Data Facet serves as a common reference model where the transformation of the input and output messages of the services is based on. Thus, dynamic data mediation, during the execution of a pre-defined process, is enabled by providing a priori the mappings and XSLT transformations for all service message elements, i.e. inputs and outputs, to the Data Facet. Mappings are created between the service message element and the instances of the Data Facet, utilizing the schemaMapping attribute to semantically annotate and associate the input and output message elements, as presented in [12]. Two types of mappings between Web Service message elements and semantics have been identified [12, 13]: a) mapping from the Web Service message element to the ontology concept, also called the “up-cast” and “up-level”, and b) transformation from the ontology concept to the message element, called the “down-cast” and “down-level”. Once the transformations are defined, two collaborative Web Services can interoperate by reusing these mappings, at run-time. Both the mappings and message transformations occur at the instance level between the WSDL (XML) and ontology instance. In addition, the creation of the meta-model of the Data Facet intends to extend the Upper EAI Ontology with well documented and formalized business data semantics. As the ENIO Data Facet does not aim at producing an additional (e-) business standard, to the numerous existing ones, it is based on an internationally standardized and promising method, called the Core Components Technical Specification (CCTS), in the development of the business data foundational meta-model. C. Functional Facet ENIO Functional Facet is designed to provide schema classifications and specified taxonomies so as to enable effective categorization of enterprise services. Thus, the Functional Facet defines formally the capabilities of enterprise services and provides classes for the annotation of services with functional semantics. This categorization of the intended functionality of the enterprise services combined with ontology-driven matchmaking algorithms supports efficient and effective discovery of published Web Services in a service registry. Furthermore, the Functional Facet assists collaborative business process design, as the participation of a specific Web Service in a collaborative business process composition scenario involves mainly the formal specification and shared understanding of the desired functionality.

The meta-model of the Functional Facet that extends the Upper EAI Ontology utilizes the Core Ontology of (Web) Services (COS) [14], which is a module of the DOLCE foundational ontology [15] that models services and their interrelationships in a domain-independent way and generalizes notions of existing conceptualizations of Web Service descriptions. The domain dependent layer of the Functional Facet provides functional descriptions of Web Services, which are annotated via OWL-S profile descriptions. The inputs and outputs of these web services are annotated using concepts of the domain dependent layer of the Data Facet of the ENIO. D. Process Template Facet The purpose of the ENIO Process Template Facet is to provide a means for defining collaborative business process templates. The meta-model of the Process Template Facet constitutes a process template ontology that follows to a large extent the MIT Process Handbook methodology [16]. The Process Template Facet provides a means to model the public views of processes, (referred to as public process views from now on) from a specific vendor or system point of view and to provide a classification and taxonomy of public process views and collaborative business processes. Figure 2, illustrates the Process Template Facet:

Figure 2: The Process Template Facet

The Process Template Facet of the ENIO is used for the manual and semi-automatic design of collaborative business processes. It is used as a classification scheme for manual and semi-automatic design and is used as a collaborative business process template for semi-automatic design. The difference between both approaches is described in the following subsections. In Figure 3, the boxes represent concepts of the Process Template Facet

Figure 3: Example of a Collaborative Business Process

Figure 3, illustrates how a collaborative business process can be created. The collaborative business process defines the public process views it consists of and the functional profiles (service descriptions) associated with the public process views. Roles are defined for each public process view and one public process view is assigned as an initiating public process view. The Process Template Facet is made up of the following classes: 1) Process; the process class distinguishes between two types of processes,, which are declared as disjoint from each other indicating that the two classes cannot represent the same concept, but are specializations of the process concept. A process is associated with the Category class; this enables the classification of processes under a certain category. The process subclasses are as follows: a) The public process view class; describes the publicly exposed processes of vendor specific systems. The public process view class is used in order to associate a group of service descriptions from the functional facet to a public process view. A public process view is also associated to exactly one (business partner) role, e.g. a “buyer” role or a “seller” role. b) The collaborative process class describes the collaborative business process templates for semiautomatic composition. A collaborative business process is defined by the collaboration of at least two public process views; therefore a collaborative process must consist of at least two public process views. Each public process view belongs to a certain category; a collaborative business process belongs to the category of the public process view that initiates the collaborative business process, i.e. the public process view that starts with the initiating request 2) Category; the category class provides a taxonomy of process categories. Public process views as well as collaborative business processes are classified under the category class. A public process view can point to any

taxonomy of the category class. However, a collaborative business process points to the category of the initiating public process view. 3) Role; the role class describes the role of the public process view. A taxonomy of roles can be provided in order to associate given public process views to a role. E.g. roles can be customer, buyer, manufacturer and seller roles. 4) Functional Profile; the functional profile class is not part of the Process Template Facet. It is part of the Functional Facet of the ENIO and describes the functionality of a service. The Process Template Facet is associated to the Functional Facet and also the Data Facet through the functional profile class. A public process view consists of one or several functional profile classes (or service descriptions) of the Functional Facet, which in turn point to one or several inputs and outputs of the Data Facet. Apart from a service description pointing to inputs and outputs of the Data Facet, a service description also points to a) a profile, which is used for discovery, b) service grounding; containing information used for grounding the service description to the respective Web Service, this is performed after the discovery of the respective services is performed and c) a behavioral model providing annotations of the inputs and outputs of a Web Service and the states of its operations. We differentiate between service descriptions and Web Services, service descriptions are the semantic annotations of the participating Web Services in an integration scenario, whereas, Web Services refer to the Web Services that can be grounded and executed. Defining public process views of the publicly exposed processes of vendor specific systems, enables the re-use of these public process views for collaborative business processes in various integration scenarios. Figure 4 illustrates an example of how the Process Template Facet is used:

Figure 4: Example of the Process Template Facet

III. COLLABORATIVE BUSINESS PROCESS DESIGN As already stated in the introduction, an executable collaborative business process can be realized as a composed Web Service orchestrating the parts of the collaborative business process that are also exposed as Web Services. For the sake of completeness, there are two distinct approaches for the coordination of Web Services from the architectural point of view: Orchestration with a central, dominating ”mediator” [17] and choreography without any centralized party, but with partial coordination tasks at each partner side (sometimes also called peer-topeer approach [17]. The combination of several existing Web Services as choreography, typically requires most of the participating Web Services to be adopted (i.e., changed) in order to be able to handle the partial coordination tasks. In case of orchestration, a composed service has to be generated (e.g. as executable BPEL file) using the existing Web Services as components. In this paper, the phrase “component Web Service” is used to refer to the Web Services used in building up the collaborative business processes (i.e. the composed Web Services). Theoretically, choreography is more general and powerful. However, up to now it is by far more complex to implement compared to orchestration. To our best knowledge currently there are no effective Web Service composition methods automating choreography-based integration. Furthermore, we believe that the choreography-based approach is not absolutely needed for the realization of EAI scenarios. Hence, in the following we focus on Web Service composition resulting in executable orchestration. Web Service composition can be structured in three sequential steps: service discovery, service composition, and service execution. While in the discovery step the required component Web Services are picked out of a set of published Web Services, in the service composition step the interaction of these discovered Web Services is coordinated and formalized (in the case of semi-automatic process design). In the third step, this formalized coordination is used to execute the component Web Services in such a way, that the required composed Web Service functionality is reached. Because the composed Web Service is used “to orchestrate” the component Web Services, the last step is sometimes referred to as orchestration (e.g., in [18], [17]). To avoid confusion in this paper, the term orchestration is only used to distinguish this kind of coordination from the choreography approach, while the third step will be called execution. In the following we introduce two alternative methods for the design of composed Web Services

implementing collaborative business processes. A. Semantically-assisted manual process design In order to assist the tedious task of manual process design, the concept of process models is employed. Process models ease the job of a business analyst realizing a business workflow within a system. A business analyst may design a workflow and semantically annotate it with the help of an ontology editor which presents the content of the ontology in a graphical way. For the end users, therefore, a set of process models covering the most common business process scenarios is provided. The end user simply needs to select a model and customize it (if necessary) and then invoke discovery to find available executable Web services to execute the process. To deal with these issues, two tasks can be identified concerning manual process design: 1. Creation of the process models 2. Customization and grounding of the process models These are each associated with a different role in the system, that is, a process model creator is not meant to customize a model himself, nor is the user as someone who customizes a model meant to create models. This method of process design supports atomic Web services for executing each of the functions in the process model (i.e. services/WSDL with one operation). This is due to the lack of knowledge of the behaviour (order of execution of operations) of the services. 1) Introduction to the manual process designer models A process model defines an abstract flow of functions and is intended to help the user to identify the necessary tasks that need to be performed for a particular process. A process model is abstract because it describes a set of functions that are not executable; instead they contain a semantic description of the service that could be used to execute them. This means that each function is shown as a black box (a placeholder for a Web Service). The model creator knows what is expected of each function, however the implementation is not specified. For this reason, process models may be used by partners from different countries and backgrounds. Since the model describes an abstract workflow, it may be executed by any Web Services that perform the functions described in the model, irrespective of how they are implemented or where they are executed. A process model has participants such as Customer, Sales Representative, Courier etc. that communicate with the process. These participants each exposing a public process view possess a role (e.g. Customer role, Sales role etc.).

Place Order

Accept Or Reject Quotation Otherwise accept?

case: accepted Customer Process Order

Get Customer Details Sales Representative

Payment MetaService

Send Order

Meta Service Provider

Confirm

End

Courier

Figure 5: Example Process Model with optional functions (dashed outline)

2) Creation of the process model A set of black boxes (representing functions) embedded in control structures needs to be created first. The next step is to annotate each black box semantically in order to allow for discovery of services to execute them. To annotate, an ontology editor that provides a visual overview of the concepts in the ontology, is used. Concepts from the second layer functional facet of the ontology may be selected to annotate the process model. The second layer of the functional facet of the ontology is the interoperability layer. This layer, being a less specific one, provides a way to annotate process models in a more generic way and hence allowing for more flexibility in communication between the functions of a process model. Once a function is associated with a concept from the Functional Facet, its inputs and outputs are known and the dataflow may be specified. An optional function is a function that is not compulsory for the process. An optional function may change the value of data but does not change the way the data flows through the process. These optional functions add extra functionality without altering the main dataflow. Optional functions may be removed from the process model during the customisation step. An optional function may however depend on another optional function and removing one might require the other to also be removed.

In order to allow for such dependencies, the following rules have been defined for sets of functions: All or none (AON) At least X (AL) At most X (AM) Exactly X (EX) *where X is a positive integer 3) Customization of the process model In a next step, a selected process model may be customized. Customization is restricted to dealing with optional functions. Optional functions and control constructs are displayed in a different manner to compulsory ones; hence the user is aware where the workflow may be modified. The rules and dependencies of optional functions are included in the process model, so it is possible to validate if a composition abides by the rules. After an optional function and/or control construct is removed it can be checked if the rules still hold. An undo operation will allow the user to go back to a previous step, so if a rule is broken it will be easy to correct the error. A collaborative business process consists of services from different vendors. Generally, several services from the same vendor participate in a process in a real-world scenario. It is important in such a case that for a certain partner role, services from the same vendor are invoked. Therefore a vendor (or a vendor’s public process view) should be chosen for each role at customization time, whose services will be used. (This concept corresponds to the “Public Process Views” as shown in Figure 3). 4) Discovery and grounding The discovery and grounding stage is the stage where an abstract process model is made executable. This involves discovering a Web Service for every function in the process. The discovery process needs to be invoked by the user but is done automatically. Discovery is done by using the semantic description for every function in the model in order to identify which Web Service could satisfy the semantic requirements the functions are annotated with. It is possible that more than one Web Service satisfy the semantic description of a function in the model. In this case, the user invoking the discovery will be prompted to select which service to use in the process. Once each function has an assigned Web service the process can be grounded. Grounding involves extracting information from the discovered Web services in order to connect the process model (which is in abstract BPEL) to these Web services. After grounding, the process model is

in executable BPEL and can be deployed on a BPEL execution engine. B. Semi-automatic process design In contrast to manual process design, semi-automatic process design is based on a Web Service composition tool that semi-automatically generates executable orchestration (which represents the integrated process) out of a list of component Web Services and a composition goal. The following figure represents a high-level abstract framework for automatic Web Service composition [24]. In Web Service composition scenarios there always exists a service requestor and a service provider. A service provider publishes services to a service repository in order to be used by service requestors, whom in turn consume the published services. Each of the service providers and requestors has their own external specifications for the service provided and the request of service respectively.

Figure 6: Automated Service Composition Framework

Automatic composition encompasses the following phases: 1. Service presentation; this phase includes the publishing of services by service providers. Services are stored in a service repository/registry like UDDI [25] for example. 2. Specification translation; service offerings and requests are represented as external specifications, whereas, the process generator (composer) of a composition system represents its service in an internal specification. Therefore, the Translator component is responsible for the translation of external service specifications to internal ones. 3. Composition of component Web Services; according to the specification of the required service provided by the service requestor. The Composer component is responsible for generating the process model (the composed service) of the service required by the requestor using services published in the service repository. Hence, the composed service defines the

control and data flow between the service requestor and the selected services. This process is referred to as orchestration. 4. Service evaluation; in the case that more than one composite Web Service is generated due to several services having the same or similar functionalities; the Evaluator component assesses the services according to their usage and these services can be selected according to a ranking mechanism. 5. Service execution; in this phase the selected composed Web Service is executed using the Execution Engine component. The composed service is executed according to the control and data flow defined in the generated process model. Numerous dimensions for classifying automatic Web Service composition have been proposed in [18] [30] [31] [32]. The key dimensions considered for this paper are the a) degree of automation; that describes the amount of user involvement required in composition, b) degree of dynamics; the ability to adapt to changes in the environment, c) degree of semantic description; the degree of formalization and semantic support, and d) the complexity of the component services; the type of component services supported. Automatic Web Service composition approaches can be classified [10] into workflow approaches [33] [34] [35] [36] and AI Planning approaches [37] [38] [39] [40] [41] [42] [43]. The Process Template Facet of the ENIO provides a means for the semi-automatic composition of the collaborative business processes, by providing a process template to semantically describe collaborative business processes, whose service descriptions can be grounded to component Web Services after the discovery of these Web Services is performed. Collaborative business processes can be defined using the Process Template Facet and can be selected and further customized according to the integration needs. For semi-automatic composition, it is sufficient that a collaborative business process describes the public process views it contains, the service descriptions associated to the public process views and the role the public process view takes. The order in which the public process views/service descriptions appear and the control flow between them is not provided in the collaborative business process templates, as it is not a requirement at this stage of semiautomatic composition. Instead this is dealt with by the composer, which is responsible for defining the control and data flow of the collaborative business process. Figure 7, illustrates the steps required for semiautomatic process composition and the associated components for each step:

Figure 7: Semi-automatic composition (steps and components)

1. The creation of the Process Template Facet concepts, such as the process categories, public process views, roles and service descriptions (part of the Functional Facet of the ENIO) and the creation and customization of the collaborative business process concepts is performed by the Process Template Editor component. 2. Service descriptions are stored in a semantically enhanced UDDI registry. A service description is associated with a profile (used for discovery), a grounding (grounding of a service description to a discovered Web Service) and a behavioural model (e.g., a semantically annotated BPEL file, which includes descriptions of the inputs, outputs and state information about the Web Service operations) The behavioural model consists of annotated states, which describe the external behaviour of a Web Service operation. It describes whether the web service is in an initial, intermediate or final state and whether the final states represent a successful or unsuccessful Web Service execution. The discovery of services is performed by the UDDI registry according to a matchmaking algorithm, which matches the service descriptions provided in the collaborative business process templates against service descriptions of executable Web Services stored in the registry. The semantic descriptions of the services are grounded to the executable services. For discovery it is assumed that the systems involved in the integration scenario are known before discovery is invoked, which significantly reduces the number of discovered services compared to the general Web Service discovery scenarios. 3. . The formulation of a composition goal is performed by the Goal Editor. A composition goal consists of two parts namely, primary goal and recovery goal. The primary goal describes the successful execution of the

Web Services involved in the collaborative business process and the recovery goal describes the unsuccessful execution of the Web Services involved in the collaborative business process. The formulation of the primary and recovery goal is based on the final successful/unsuccessful states extracted from the behavioural models of the discovered services, respectively. 4. The Composer component takes a list of the discovered Web Services and the composition goal as input and transforms this into an internal format in order to formulate a composition plan that is based on the description of the composition goal. A composed service is successful if primary and recovery goals are reachable. The generated plan includes the control and data flow of the component Web Services. Once the plan is generated it is transformed into an executable composed Web Service. 5. An orchestration engine is responsible for the deployment and execution of the executable composed Web Service. There are composers to which our approach of semiautomatic composition can be directly grounded to, e.g., Web Service composition tool described in [27], [28], [29]. The Web Service composition tool in [29] focuses on service composition and service execution using a Web Service orchestration engine (BPEL). Service composition is addressed using AI planning techniques. Therefore, the problem of service composition is addressed by planning, i.e. the composition requirements are expressed as a composition goal controlling a planning domain. The list of component Web Services is translated into a single planning domain. The composer takes this planning domain and the composition goal as input and automatically produces (if possible) a composition plan as output. The composition approach can be summarized into the following phases: 1. Transformation of the behavioural models of the component Web Services participating in the composition into an internal planning domain used by the planner. 2. Formulation of a composition goal, which is used by the planning domain. 3. Automatic creation of an internal plan based on the planning domain and the composition goal. 4. Transformation of the created plan into an executable composed Web Service (BPEL). 5. Deployment and execution of the composed Web Service. Our approach for semi-automatic design can be grounded to the above mentioned approach after the

discovery of the respective Web Services and the formulation of the composition goal is performed. The behavioural descriptions of the discovered component Web Services can be transformed into a format understandable by the composer in order to define the control and data flow of the component Web Services and to create the plan for composition according to the defined composition goal. When a suitable plan is generated, the plan is transformed into a format that can be executed by an orchestration engine. IV. CONCLUSION AND FUTURE WORK In this paper we have introduced two methods for the creation of collaborative business processes (in EAI scenarios) based on the semantic enrichment of the participating Web Services in the integration scenarios. The advantage of using semantics is that there is no need for the underlying systems to be compatible on a data level and hence the integration process is faster and also affordable, which is most important for SMEs. Both methods rely on the same ontological concepts (i.e. the ENIO Process Facet Template) but solve the problem in different ways. Semantically assisted manual process design uses predefined semantically annotated abstract collaborative business process models with control and data flow defined, whereas semi-automatic design deals with collaborative business processes whose control and data flow are defined by planning techniques using the behavioral descriptions of the discovered component Web Services and a composition goal. Both approaches result in an executable process definition (BPEL), but the methodology is significantly different from the BPEL process creation using existing tools since these do not support semantic annotation. The ideas introduced in this paper may be used in collaborative business environments where underlying applications include semantic Web technologies. As a part of our ongoing research we are in the process of specifying and implementing the necessary tools for annotating and editing so that the conceptual results presented herein become also usable in real scenarios. There are already concrete use cases defined in different application fields for which the concepts introduced in this paper will be used as evaluation. Currently, the two approaches work independently of each other and a harmonized (combined) version could be foreseen as future work.

REFERENCES [1] [2]

[3] [4] [5] [6] [7] [8] [9] [10]

[11]

[12]

[13]

[14] [15]

[16]

[17] [18] [19]

[20] [21] [22] [23] [24]

[25] [26]

[27]

[28]

J. Lee, K. Siau and S. Hong, “Enterprise Integration with ERP and EAI”, In Communications of the ACM 46, 2003, No. 2, pp. 54-60. C. Bussler, “The Role of Semantic Web Technology in Enterprise Application Integration”, In IEE Data Engineering Bulletin 26, 2003, No. 4, pp. 62 – 68. D.S. Linthicum, “Enterprise Application Integration”, In AddisonWesley Information Technology Series, 2000. D.S. Linthicum, “B2B Application Integration!”, Boston, MA, Addison-Wesley, 2001 D.S. Linthicum, “Next Generation Application Integration”, Boston, Addison-Wesley, 2004. D. Serain, “Middleware and Enterprise Application Integration”, Springer, 2002. W. Keller, “Enterprise Application Integration: Erfharungen aus der Praxis”. Dpunkt Verlag, 2002. M. Stal, “Web Services Beyond Component-Based Computing”, In Communications of the ACM 45, 2002, No. 10, pp. 71 – 76. P. Holland, “Building Web Services From Existing Application”, In EAI Journal, 2002, pp. 45 – 47. J. Rao and X. Su, “A Survey of Automated Web Service Composition Methods”, In Proceedings of the First International Workshop on Semantic Web Services and Web Process Composition, SWSWPC, 2004. D. McCarthy, “Web Services as a tool for Enterprise Application Integration”, School of Computer Research Paper (ITSM), Dublin Institute of Technology, 2004. M. Nagarajan, K. Verma, A. Sheth, J. Miller and J. Lathem, “Semantic Interoperability of Enterprise Services – Challenges and Experiences”, IEEE International Conference on Enterprise Services (ICWS), 2006. J. Farrell and H. Lausen, (2006, September 28), Semantic Annotations for WSDL, W3C Working Draft, Available: http://www.w3.org/TR/sawsdl/ Core Ontology of (Web) Services (COS), Available: http://cos.ontoware.org/ C. Masolo, S. Borgo, A. Gangemi, N. Guarino, A. Oltramari and L. Schneider, (2002, August), The WonderWeb Library of Foundational Ontologies, WonderWeb Deliverable D17, Available: http://wonderweb.semanticweb.org T.W. Malone, K. Crowston and G.A. Herman, “Organizing Business Knowledge: The MIT Process Handbook”, Cambridge, MA, MIT Press, 2003. D. Berardi, “Automatic Service Composition Models, Techniques and Tools”, PhD thesis, Universita di Roma, “La Sapienza”, 2005. R. Hull and J. Su, “Tools for Composite Web Services: A Short Overview”, In ACM SIGMOD Record 34, 2005, No. 2 Business Process FUSION based on Semantically-enabled Serviceoriented Business Applications, State of the Art, Public Deliverable, D1.1, The FUSION-IST-63510 Project 2006 OWL-S: Semantic Markup for Web Services, Available: http://www.daml.org/services/owl-s/1.0/owl-s.html Web Service Modeling Ontology, Available: http://www.wsmo.org/ Semantic Web Services Framework (SWSF) Overview, Available: http://www.w3.org/Submission/SWSF/ Web Service Semantics – WSDL-S, Available: http://www.w3.org/Submission/WSDL-S/ J. Rao and X. Su, “A Survey of Automated Web Service Composition Methods”, In Proceedings of the 1st International Workshop on Semantic Web Services and Web Process Composition, SWSWPC 2004, LNCS, San Diego, USA, 2004. UDDI Version 2.04 API Specification, (2002, July 19), Available: http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.htm A. Bouras, P. Gouvas, A. Friesen, A. Alazeib and G. Mentzas,“ENIO: An Enterprise Application Integration Ontology”, submitted for publication to a conference. M. Pistore, P. Bertoli, E. Cusenza, A. Marconi and P. Traverso, “WSGen: A Tool for the Automated Composition of Semantic Web Services”, In Proceedings of the 3rd International Semantic Web Conference (ISWC), Hiroshima, Japan, 2004 M. Pistore, P. Traverso and P. Bertoli, “Automated Composition of Web Services by Planning in Asynchronous Domains”, In Proceedings

[29]

[30] [31]

[32]

[33]

[34]

[35]

[36]

[37]

[38]

[39] [40]

[41]

[42]

[43]

of the International Conference on Automated Planning and Scheduling (ICAPS), Monterey, California, U.S.A, 2005. M. Pistore, L. Spalazzi, P. Traverso, “A Minimalist Approach to Semantic Annotations for Web Processes Compositions”, 3 rd European Semantic Web Conference (ESWC), Budva, Montenegro, 2006. D. Berardi, G. De Giacomo, M. Mecella, “Basis for Automatic Service Composition”, In: Tutorial at WWW, Chiba, Japan, 2005 I.B. Arpinar, R. Zhang, B. Aleman-Meza, A. Maduko, „Ontologydriven Web Services Composition Platform”, In: Information Systems and E-Business Management 3, No. 2, 2005 S.C. OH, D. Lee, S.R.T. Kumara, “A comparative illustration of AI planning-based web services composition”, In ACM SIGecom Exchanges 5, No. 5, 2006 P. Grefen, K. Aberer, Y. Hoffer, H. Ludwig, “CrossFlow: Crossorganizational Workflow Management in Dynamic Virtual Enterprises”, 2000 F. Casati, S. Ilnicki, and L. Jin, “Adaptive and dynamic service composition in EFlow”, In proceedings of the 12th International Conference on Advanced Information Systems Engineering (CAiSE), Stockholm, Sweden, June 2000 F.Casati, M. Sayal, and M.-C. Shan, “Developing e-services for composing e-services”, In proceedings of the 13th International Conference on Advanced Information Systems Engineering (CAiSE), Interlaken, Switzerland, June 2000 H. Schuster, D. Georgakopoulos, A. Cichocki, and D. Baker, “Modelling and composing service-based and reference process-based multi-enterprise processes”, In proceeding of the 12th International Conference on Advanced Systems Engineering (CAiSE), Stockholm, Sweden, June 2000 D. McDermott, “Estimated-regression planning for interactions with Web services”, In proceedings of the 6th International Conference on AI Planning and Scheduling, Toulouse, France, 2002. S. McIlraith and T.C. Son, “Adapting Golog for composition of Semantic Web services”, In proceedings of the 8 th International Conference on Knowledge Representation and Reasoning (KR2002), Toulouse, France, April 2002. S. McIlraith, T.C. Son, and H. Zeng, “Semantic Web Services” IEEE Intelligent Systems, 16(2): 46-53, March/April 2001. B. Medjahed, A. Bouguettaya, and A.K. Elmagarmid, “Composing Web Services on the Semantic Web”, The VLDB Journal, 12(4), November 2003. S.R. Ponnekanti, and A. Fox, “SWORD: A developer toolkit for Web service composition”, In proceedings of the 11th World Wide Web Conference, Honolulu, HI, USA, 2002. E. Sirin, J. Hendler, and B. Parsia, “Semi-automatic composition of Web services using semantic descriptions”, In proceedings of Web Services: modeling, Architecture and Infrastructure workshop in conjunction with ICEIS2003, 2002. D. Wu, E. Sirin, J. Hendler, D. Nau, and B. Parsia, “Automatic Web services composition using SHOP2”, In Workshop on Planning for Web Services, Trento, Italy, June 2003.