ontology-based modeling of service processes

IADIS International Conference Applied Computing 2007

ONTOLOGY-BASED MODELING OF SERVICE PROCESSES AND SERVICES Rainer Schmidt Aalen University of Applied Sciences Beethovenstraße 1, 73430 Aalen, Germany Rainer [email protected]

Christian Bartsch Information Process Engineering (IPE) Research Center for Information Technologies (FZI) Haid-und-Neu-Str. 10-14, 76131 Karlsruhe, Germany [email protected]

ABSTRACT Service processes and services became an important topic in industry. For example, many enterprises strive to optimize their IT-Services by using process-oriented approaches. Service Processes often cross organizational boundaries: therefore it is highly important that both service provider and service client have a common understanding of terms. A widespread means to achieve this goal are ontologies. However, to completely capture the semantics of service processes and services, an appropriate structure of the ontology has to be developed. The ontology proposed in this paper has four layers and uses eight orthogonal perspectives to differentiate the elements of each layer. By this means, it is possible to capture both the static and the dynamic semantic of service processes and services. Using the ontology, it is possible to clarify the terms in the service processes across organizational boundaries and to avoid the creation of homonyms and synonyms. Thus, the implementation and execution of service processes and services is facilitated. KEYWORDS ontology, service, service process, process model

1. INTRODUCTION Service processes and services attract much interest in industry. For example, many enterprises strive to optimize the allocation and management of their IT-Services by using process-oriented approaches. However, providing cross-organizational service processes and services often creates a higher effort and higher cost than expected. Significant reasons are synonyms and homonyms in the process and service models. These synonyms and homonyms easily come into being, because different organizations have to work together. A common means to avoid the creation of synonyms and homonyms are ontologies. However, the design of an ontology for service processes and services has to take into consideration that the modeling of service processes and services is more complex than of standard business processes. Furthermore, service processes and services are two tightly intertwined concepts. Therefore, this paper develops an ontology to avert synonyms and homonyms in service process models and services. The ontology takes into account the special properties of service processes and services. To develop this ontology, the paper will continue as follows. In section 2, basic terms are clarified. Section 3 is devoted to the discussion of related work. In section 4, the structure of the ontology using layers and socalled perspectives is developed. Section 5 describes the use of the ontology in a project for modeling the incident management process of a medium-sized enterprise. Finally a conclusion and outlook is given.

67

ISBN: 978-972-8924-30-0 © 2007 IADIS

2. TERMS Ontologies are „explicit specifications of a conceptualization“ [Grub95]. They capture knowledge of a domain in an explicit and formal way to share it with others [SuSt05]. An ontology defines explicitly the used concept types and the constraints which have to be observed [SuSt05]. They refer to a specific domain and support a certain goal. The knowledge encoded in the ontology should be inter-subjective, which means it should comply with a common understanding of a domain. The question if an objective ontology is possible is a rather philosophical one and shall not be discussed here. Ontologies are defined using representation languages such as OWL DL [KnFe04] or RDF [MaMi04]. Ontologies offer a number of benefits [NoMc01]. Among others, they allow to create a common understanding of terms and their relationships between people or software agents and thus facilitate cooperation. Information can be interchanged and information from different sources can be aggregated easier. The creation of a common understanding of terms and their relationships also enables the reuse of domain knowledge by exchanging ontologies. In addition ontologies explicitly allow the handling of domain knowledge and assumptions. Thus, it can be easily adapted to changing requirements and is not (implicitly) hard-wired into applications. In addition, the separation of domain knowledge from operational knowledge is a benefit offered by ontologies. Therefore, processes can be designed independently from a domain. Finally, ontologies create the possibility to analyze domain knowledge. Processes are the ordered execution of activities to achieve one or multiple goals. There are low-level goals such as the production of a product and high-level goals such as increasing customer satisfaction. Processes have both static and operational semantics. The static semantics comprise the goal and the definition of the process elements. The operational semantics comprises the execution order of activities and their pre- and post conditions. A process model contains an abstract view of the process. Process models consist of model elements defined in a meta-model. The meta-model defines the rules for combining the process model elements. Thus, the “real” process is formalized as a process model using the model elements and applying the rules defined in the process meta-model. A process model defines allowed paths for the execution of the process. The process model defines the sequence of activities to be executed in the process and rules for executing activities depending on preconditions. For example, the model of order processing defines the activities to be performed to process the order and the corresponding rules like “Reject the order if the ordered product is out of production”. The process model is a template for creating process instances. Process instances (or instances for short) represent the concrete processing of an order, e.g. the processing of order number 4711.

3. RELATED WORK First basic approaches to formalize services can be found in the work of Fähnrich and Auer [FäAu03]. Services are formalized in their work using a product data management approach. An approach that emphasizes the service level agreement perspective is presented in [ScBK05]. An ontology-based approach for formalizing Petri Net-based business processes is given in [KoOb05]. The semantic alignment of business processes using ontologies is described in [BEKO06]. Ontologies are also used to represent the methods of modeling methods in [RoGr02]. Early approaches for perspective-oriented meta-models can be found in the workflow area. A meta-model describing workflows based on aspects has been introduced in the work of Jablonski [JaBS97]. Another interesting approach is the development of an open and formalism independent meta-model for business processes by [AxKR05]. This work is based on modeling business process aspects and its relations to each other utilizing the Unified Modeling Language (UML) to allow a simpler operationalization of business process reference models. [BWFK04] designs and develops a simple layerbased model for managing service data. The proposed model is a first step towards ontology. The authors describe very generally IT-Services as composition objects with reusable characteristics. Without getting into modeling details [ZdHe05] illustrates a resource perspective concept. Fettke and Loos give a comprehensive state-of-the-art overview on reference modeling research [FeLo03] that is related to ontology construction. For modeling processes, a large variety of approaches is available, yet. For example, processes are formalized using Event-driven Process Chains (EPC, ARIS) [Sche91] or Petri Nets [LeOb04]. Furthermore there are XML-based approaches such as the Business Process Modeling Notation (BPMN) [BPMN06] or

68


the Business Process Execution Language for Web Services (BPEL4WS) [BPEL03]. BPEL4WS allows to specify business processes and to define the Web Services to be used for executing the specified business process [LeRo02]. BPEL4WS can be seen as a meta-model that provides a set of elements and rules to describe business processes. The focus of process models is the representation of the operational semantics. That means the sequence of activities and their dependencies. Only few models also try to capture the static semantics of the process, such as organization charts in ARIS [Sche91]. Up to now, ontologies are primarily used for analyzing the properties of modeling methods but not for supporting the models itself [RoGr02].

4. STRUCTURE OF THE ONTOLOGY Ontology-based process modeling augments the traditional process modeling by introducing an ontology to unify the use of terms in multiple process models, as shown in the example in Figure 1. There are processes in the organizations A, B, C and D that interact to provide a service. Without an ontology, a multitude of problems appears on the interfaces of the processes, due to the inconsistent use of terms. Different terms are used for the same meaning (synonyms) and the same term is used for different meanings (homonyms). Using the ontology, each process model is annotated using the process element classes defined in the ontology. Thus, the semantics of each process element is unambiguously defined and all process models use terms identically. Therefore, the creation of synonyms and homonyms is averted. Organization A

Organization B

Process model

Process model

Ontology

Process model

Organization C Process interaction

Process model

Organization D Annotation

Figure 1. Ontology-based process modeling

An ontology for ontology-based process modeling has to completely reflect the static and dynamic semantics of the service processes and services. Furthermore, it has to be extensible to allow the integration of new service processes and services. To achieve these goals, the ontology to be created shall be organized by four layers and eight perspectives as shown in Figure 2. The layers define the abstraction levels of the ontology. The two top layers are organization independent, the others organization specific. The first layer is called the basic layer. It defines the concepts to describe the perspectives in the second layer. Using this approach, extensibility is achieved, because additional perspectives in the second layer can be easily integrated using the concepts of the basic layer. The second layer is called perspective layer. On the second layer, perspectives and their elements are defined using the concepts defined on the first layer. On the third layer abstract process element classes are defined, which define generic process element classes specific to an organization. For example, the concept “activity” on the second layer may be refined to “order activity”, “marketing activity” etc. Generic means, that they have to be further refined before being used for process modeling. This is done on the fourth layer. The concrete process element classes defined on the fourth layer are used to mirror one or more process elements in the process model. New classes can be easily added and associated to one of the abstract process element classes of the third layer. The use of a oneto-many relationship instead of a one-to-one relationship is crucial to detect synonyms and homonyms. Thus, the semantic identity or non-identity of process elements can be expressed. Synonyms in the process model

69

ISBN: 978-972-8924-30-0 © 2007 IADIS

can be detected because process elements with different names point to the same concrete process element class. Homonyms can be found by detecting that two equally named process elements point to different process element classes. Basic layer

Functional Perspective

Operational Perspective

Informational Perspective

Organisational Perspective

Control Perspective

Interaction Perspective

Ressource Perspective

ServicePerspective

Perspective layer Activity

Ordering

Production

Request offer

Evaluate offer

Abstract process element classes

Marketing

Concrete process element classes

Annotation

Request offer

Evaluate

Process model

Figure 2. Structure of the ontology

Now the perspectives used for organizing the ontology shall be depicted in detail. The perspectives are orthogonal to the layers. Perspectives mirror aspects of reality evolving independently from each other. They allow to organize the objects of each layer according to their task in the definition of the service processes and services. This is necessary to capture appropriately the semantics of the service processes. Service processes contain independently evolving parts such as data structures and organizational structures: For example, data structures involved in a certain process can fundamentally change without evoking any modification within the organizational structure of the company. The identification and separate handling of perspectives is a precondition to achieve flexibility and maintainability of process models. Without the separation of different perspectives, modeling areas that evolve independently are intermixed: Changes in one perspective cause a multitude of side effects creating a high effort to implement changes and increase the probability of erroneous changes drastically. The mixing of perspectives causes the creation of crosscutting functionality: Functionality that could be described by one single perspective element is intermixed with other perspectives. If a change is necessary, not only one element but also a multitude of elements has to be changed. Furthermore, indicated changes are not fulfilled completely and consistently. An example of such a mixture of perspectives is the “flow dependence” of application programs described by [LeRo97]. Flow dependence means, that application programs contain a predefined control flow, making them inflexible to business process changes. Another example is the embedding of interaction protocols into objects requiring a multitude of objects to be changed if the interaction protocol is changed. Therefore, interaction protocols should be handled separately from objects [AkBe92]. There are five basic perspectives contained in every type of process. The five basic perspectives are the functional, the operational, the informational and the organizational perspective. The functional perspective describes what the process has to do; particularly it defines the process goal. The operational perspective specifies activities executed during the process. The control perspective defines, when and under which preconditions activities are performed. The informational perspective specifies the information that shall be exchanged between activities. The organizational perspective associates roles with activities. For example, the definition of the organizational perspective contains concepts such as role, organizational unit etc. These

70


basic perspectives are well known and have been already discussed in numerous publications, for example, [JaBS97], [AxKR05]. However, the basic perspectives do not cover the functionality of service processes and services appropriately. Therefore, three additional perspectives are introduced to mirror entirely the semantics of services and service processes. They are called service, resource and interaction perspective and are defined in detail in the following.

4.1 Service Perspective In the service perspective, the service and the quality of a service are defined using a set of properties. Each property owns a marginal-value that is compared to the real value. A pre-defined procedure measures the real level. Each measurement has a dedicated responsible role. If the real value does not comply with the marginal-value contract, penalties are the consequence. The service level agreement also defines the framework for the concrete service by providing duties of the service provider and the service requester. These duties are subordinated services. Figure 3 illustrates theses relationships. Service Subordinated Service

0..* includes

Provider Responsibilities

Internal Role

1 1..* responsible

1

Requester Responsibility 1..* responsible

1

Responsibilities

0..*

Role

External Role 1

includes

1..*

Service Level Agreement responsible 1 has 1..*

0..*

Real Value

Property

1

+vergleich:boolean

1..*

1

1

Measurement

provides

Measurement Procedure 1..* 1 defines

has 1

1 is compared with

has 1 Marginal Value

1

Figure 3. Service perspective

Service level agreements can be established between internal and external parties or internal parties only. For example, if only internal parties are involved, the service level agreement is called operational level agreement. A service level agreement between an internal service requester and an external service provider is called underpinning contract. It is usually used to define the quality of outsourced sub-services.

4.2 Interaction Perspective An important characteristic of service processes is their high degree of division of labor and the tight integration of external parties such as customers and subcontractors. These parties have to be integrated to a much larger extent than in traditional business processes. Therefore, it is necessary to capture appropriately the interaction semantics. Interactions are captured in the interaction perspective (see Figure 4).

71

ISBN: 978-972-8924-30-0 © 2007 IADIS

Activity

External Activity

1

1

1 1 Interaction Step 1 1

Post Condition 1

Pre Condition 1 has

has 1..*

is composed of Schema

Interaction 1..*

1 exchanges

Unidirectional Interaction Bidirectional Interaction

Complex Interaction

Figure 4. Interaction perspective

Interactions standardize protocols required for cooperation between different parties like the clearing of a document. By this means, there is a unique and central definition for the protocol. Using the interaction perspective, interactions are abstracted, encapsulated and prepared for reuse. Often, interactions do not determine each step but only pre-and the post-conditions. That means that they define only the condition to be met to start the interaction and the condition to be met to finish the interaction. If the interaction perspective is not explicitly defined, many modeling elements contain parts of the interaction. Thus, a change of the interaction would require the change of all these elements, which is rather inflexible. Furthermore, there is the danger, that inconsistencies are created. Additionally the information to be extended is specified. Interactions may be unidirectional, bidirectional or complex.

4.3 Resource Perspective An important difference between service processes and ordinary business processes is the intensive use and integration of external resources, as shown in figure 5. Request Procedure

Service Process

1 Role

1

0..*

Procedure

Integration Procedure transforms

executes 0..* Return Procedure

Figure 5. Resource perspective

72

Ressource


However, accessing, maintaining and managing external resources is much more complex compared to internal resources. For example, external resource cannot be removed or expanded as easy as internal resources could. Therefore, a special procedure is necessary to obtain, to integrate and to remove the resource. Resources are transformed by service processes.

5. EVALUATION PROJECT The ontology presented in this paper was used within a project for modeling the incident management process of a medium-sized enterprise. The project was initiated, because synonyms and homonyms in the service process and service models created many misunderstandings and confusions especially when cooperating with external service providers. The project started with an analysis of the existing model of the incident management process and its associated services as shown in Figure 6, (1). The incident process is modeled using an Event-driven Process Chains approach [Sche91]. During the analysis a process ontology was created (2), using the layered and perspective-oriented approach presented in this paper. The ontology has been implemented with the Protégé [PROT] tool using the OWL-plug-in [KnFe04]. After the ontology had been finalized, the ontology was published within the company and especially to the external service providers (3). Thus, all participants of the process have been able to align their processing using the terms of the ontology (4). By using the aligned processes, a multitude of misunderstandings could be cleared up and the process performance improved. (1) Process Analysis

Process model

(2) Ontology Creation

Ontology (4) Alignment

(4) Alignment (3) Publication

Process model

Service provider A

Process model

Service Provider B

Figure 6. Evaluation project

6. CONCLUSION Services and service processes are defined and executed in a highly cross-organizational manner. Therefore, it is crucial to clarify the semantics of all process elements. Particularly synonyms and homonyms should be avoided. A common approach to achieve these goals is the use of an ontology. However, an ontology has to be properly structured to fully capture the semantics of services and service processes. Therefore, this paper presents a multi-layer ontology that is further organized using perspectives. The separate handling of perspectives in the ontology allows averting side effects when implementing changes and the creation of crosscutting functionality. Three additional perspectives were introduced to capture the augmented functionality of services and service processes when compared to standard business processes. The interaction perspective represents interactions between activities of different processes and thus allows standardizing them and makes them reusable. The resource perspective represents external resources that have to be appropriately obtained, integrated, administered and returned. The service perspective defines services and their quality. Using the layered and perspective-oriented ontology, a consistent and complete

73

ISBN: 978-972-8924-30-0 © 2007 IADIS

definition of services and service processes can be obtained that is free of synonyms and homonyms. Thus, the implementation and execution of cross-organizational services and service processes is facilitated.

REFERENCES [AkBe92] Aksit, M.; Bergmans, L.: Obstacles in Object-Oriented Software Development. In: Proceedings OOPSLA, pp. 341–358, 1992. [AxKR05] Axenath, B., Kindler, E., Rubin, V.: An Open and Formalism Independent Meta-Model for Business Processes. In: Proceedings of the Workshop on Business Process Reference Models (BPRM 2005), Nancy, 2005. [BEKO06] Brockmans, S.; Ehrig, M.; Koschmider, K.; Oberweis, A.; Studer, R.: Semantic Alignment of Business Processes. In: Proceedings of the Eighth International Conference on Enterprise Information Systems (ICEIS 2006), pp. 191-196. INSTICC Press, Cyprus, 2006. [BPEL03] Business Process Execution Language for Web Services (Version 1.0) ftp://www6.software.ibm.com/software/developer/library/ws-bpel.pdf, 2003. [BPMN06] Business Process Modeling Notation. http://www.omg.org/cgi-bin/apps/doc?dtc/06-02-01.pdf, 2001. [BWFK04] Böhmann, T.; Winkler, T.; Fogl, F.; Krcmar, H.: Servicedatenmanagement für IT-Dienstleistungen: Ansatzpunkte für ein fachkonzeptionelles Referenzmodell. In: Becker, J.; Delfmann, P. (Hrsg.), Referenzmodellierung: Grundlagen, Techniken und domänenbezogene Anwendung, pp. 99-124. Physica, Heidelberg, 2004. [FäAu03] Fähnrich, K.-P.; Auer, S.: Product Models in Service Engineering. In: Proceedings der 17th International Conference on Production and Research 2003, Blacksburg, VA, USA. 2003. [FeLo03] Fettke, P. and Loos, P. (2003) Ontological Evaluation of Reference Models using the Bunge-Wand-Weber Model, Proceedings of the Ninth Americas Conference on Information Systems. (pp. 2944–2955) [Grub95] Gruber, T. R.: Towards principles for the design of ontologies used for knowledge sharing. International Journal of Human-Computer Studies, 43(5/6):907-928, 1995. [JaBS97] Jablonski, S.; Böhm, M.; Schulze, W.: Workflow-Management: Entwicklung von Systemen und Anwendungen — Facetten einer neuen Technologie. Dpunkt Verlag, Heidelberg, 1997. [KnFe04] Knublauch H., Fergerson R. W., Noy N. F., Musen M. A: The Protégé OWL Plugin: An Open Development Environment for Semantic Web Applications. Third International Semantic Web Conference - ISWC 2004, Hiroshima, Japan (2004) [KoOb05] Koschmider, A.; Oberweis, A.: Ontology based Business Process Description. In: Proceedings of the CAiSE´05 WORKSHOPS, no. 2, pp. 321-333, Portugal, 2005. [LeOb04] Lenz, K.; Oberweis, A.: Workflow Services: A Petri Net-Based Approach to Web Services. In: Proceedings of Int. Symposium on Leveraging Applications of Formal Methods, pp. 35-42, Cyprus, 2004. [LeRo02] Leymann, F.; Roller, D.: Business processes in a Web services world: A quick overview of BPEL4WS. ftp://www6.software.ibm.com/software/developer/library/ws-bpelwp.pdf, 2002. [LeRo97] Leymann, F.; Roller, D.: Workflow-based applications. IBM Systems Journal, 36(1), 1997. [NoMc01] Noy, N. F.; McGuinness, D. L.: Ontology Development 101: A Guide to Creating Your First Ontology. Stanford Knowledge Systems Laboratory Technical Report KSL-01-05 and Stanford Medical Informatics Technical Report SMI-2001-0880 (March), 2001. [MaMi04] Manola, F.; Miller, E.: RDF Primer - W3C Recommendation. http://www.w3.org/TR/rdf-primer, 2004. [PROT] http://protege.stanford.edu/ [RoGr02] Rosemann, M.; Green, P.: Developing a meta model for the Bunge-Wand-Weber ontological constructs. In: Information Systems (27), pp. 75-91, 2002. [ScBK05] Schermann, M.; Böhmann, T.; Krcmar, H.: Towards a Reuse of Product Related Concepts for Service Data Management - an Ontology Approach. In: Proceedings of the Informatik 2005 - Workshop PRODIS, Bonn, 2005. [Sche91] Scheer, A.-W.: ARIS – Modellierungsmethoden, Metamodelle, Anwendungen; Springer, Berlin, 1991. [SuSt05] Sure, Y.; Studer, R.: Semantic Web Technologies for Digital Libraries. www.aifb.uni-karlsruhe.de/ WBS/ysu/publications/2005_sw_for_dl.pdf, 2005. [ZdHe05] Zdravkovic, J.; Henkel, M.: Enabling Flexible Integration of Business and Technology in Service-based Processes. In: Proceedings of the CAiSE’05 (BPMDS Workshop), pp. 107-114, 2005.

74