Semantic Business Process Management: Applying Ontologies in BPM

Semantic Business Process Management: Applying Ontologies in BPM

Dimka Karastoyanova (University of Stuttgart, Germany), Tammo van Lessen (University of Stuttgart, Germany), Frank Leymann (University of Stuttgart, Germany), Zhilei Ma (University of Stuttgart, Germany), Joerg Nitzche (University of Stuttgart, Germany) and Branimir Wetzstein (University of Stuttgart, Germany)
Copyright: © 2009 |Pages: 19
DOI: 10.4018/978-1-60566-288-6.ch014
OnDemand PDF Download:
No Current Special Offers


Even though process orientation/BPM is a widely accepted paradigm with heavy impact on industry and research the available technology does not support the business professionals’ tasks in an appropriate manner that is in a way allowing processes modeling using concepts from the business domain. This results in a gap between the business people expertise and the IT knowledge required. The current trend in bridging this gap is to utilize technologies developed for the Semantic Web, for example ontologies, while maintaining reusability and flexibility of processes. In this chapter the authors present an overview of existing technologies, supporting the BPM lifecycle, and focus on potential benefits Semantic Web technologies can bring to BPM. The authors will show how these technologies help automate the transition between the inherently separate/detached business professionals’ level and the IT level without the burden of additional knowledge acquisition on behalf of the business professionals. As background information they briefly discuss existing process modeling notations like the Business Process Modeling Notation (BPMN) as well as the execution centric Business Process Execution Language (BPEL), and their limitations in terms of proper support for the business professional. The chapter stresses on the added value Semantic Web technologies yield when leveraged for the benefit of BPM. For this the authors give examples of existing BPM techniques that can be improved by using Semantic Web technologies, as well as novel approaches which became possible only through the availability of semantic descriptions. They show how process model configuration can be automated and thus simplified and how flexibility during process execution is increased. Additionally, they present innovative techniques like automatic process composition and auto-completion of process models where suitable process fragments are automatically discovered to make up the process model. They also present a reference architecture of a BPM system that utilizes Semantic Web technologies in an SOA environment.
Chapter Preview


The goal of this chapter is to present how model transformation and refinement techniques can be applied to produce executable code out of business process models. The chapter shows how model-driven architecture (MDA) techniques have been applied with success to the domain of business process modeling. More in detail, once a business process has been modeled using some language, there are two main alternatives to be considered in order to run the process model using a workflow execution engine (Figure 1). The first involves the direct interpretation of the model, the second the compilation of the model into a lower-level representation amenable to more efficient execution.

Figure 1.

Interpreted (left) vs. compiled (right) process execution


As an example case study, the chapter shows how the idea of compiling business process models has been driving the design of the JOpera for Eclipse workflow management tool. JOpera presents users with a simple, graph-based process modeling language with a visual representation of both control and data-flow aspects. As an intermediate representation, the graphs are converted into Event-Condition-Action rules, which are further compiled into Java bytecode for execution.

These transformations have been fully implemented in the JOpera process compiler in a completely transparent way, where the generated Java executable artifacts are kept hidden from users at all times (i.e., even for debugging process executions, which is done using the original, high level notation). We evaluate our approach by discussing how using a compiler has opened up the several possibilities for performing optimization on the generated code and also simplified the design and positively impacted the quality of the corresponding workflow engine architecture.

This chapter introduces with an example a hierarchy of business process meta-models, leading from abstract, high level and graphical representations suitable for human consumption, down to lower-level languages geared towards efficient execution by a machine. Whereas for didactical purposes (and space limitations) the example presented in this chapter is focused on representations for modeling control-flow aspects, JOpera follows a similar approach with respect to the data flow and the resource perspective of the workflow models. We define relationships and transformations between the representations, in order to support the automatic refinement, optimization and compilation of models in one direction. We also present the abstraction operations required in the reverse direction in order to provide support for “source-level” monitoring and interactive debugging of the execution of business process models.

The rest of this chapter is structured as follows. A motivation for introducing process compilation (as opposed to interpretation and model refinement) is presented in the following Section. We then briefly enumerate in Section ‘Process Representations’ different abstraction levels and viewpoints that can be used to represent a process model that is meant to be compiled for execution using JOpera. In the following section, we show a concrete example of how a process model can be transformed between these representations. In the ‘Architecture’ Section, we present the design of the architecture of the JOpera workflow engine, emphasizing the role played by its compiler. Before drawing some conclusions, we evaluate the benefits and limitations of our approach in the ‘Discussion’ Section.



Workflow engines traditionally play the role of business process language interpreters. Why should a compiler be used instead of an interpreter? Direct interpretation of process descriptions is the typical approach of most workflow execution engines. In the simplest case, the model description as it is specified by the process modeler is directly fed into the workflow engine, which uses it to initialize the state of a new workflow instance (e.g., stored in a database) and navigate over (or analyze) the control flow dependencies between tasks to determine the partial order in which tasks should be executed. The advantage of this approach lies in the portability of the process models (which can be interpreted by engines running on different hardware/operating system/database platforms). As with most interpreted languages, however, the disadvantage lies in the higher runtime overhead of the execution and in the complexity of the runtime engine infrastructure featuring support for exception handling, late binding, and flexible, ad-hoc execution.

Key Terms in this Chapter

Service-Oriented Architecture (SOA): is the architectural style for service-oriented computing. By identifying agnostic, self-contained services that encapsulate high-level business concepts it achieves a high degree of reusability. The key concepts of an SOA are “service consumers”, “service providers” and a “service discovery” which enable loose coupling between components.

BPEL for Semantic Web Services (BPEL4SWS): is comprised of a set of specifications that in combination facilitate the orchestration of both, Web Services and semantic Web Services. It uses an extension of BPEL that provides for an interaction model that is independent of WSDL, semantic Web Service description frameworks like OWL-S and WSMO to specify the capabilities the process provides and the capabilities a process requires from its partners. Additionally it defines a grounding format to enable Web Service based communication with partner (semantic) Web Services.

Ontology: is one of the essential ingredients in the layered technologies of the Semantic Web. An ontology provides a vocabulary of consolidated concepts arranged in types and categories in well-defined structure for unambiguous use in a specific domain. An ontology in computer science is normally accompanied with a language, usually in an XML representation, for defining the vocabulary and specifying the relationships between the concepts in the vocabulary, e.g. Web Ontology Language (OWL), and Web Services Modeling Language (WSML).

Semantic Web Services (SWS): is an approach to combine (in particular WSDL-based) Web services with Semantic Web technologies (in particular ontologies), in order to achieve more automation in discovery, selection, and invocation of Web services. Web service interface descriptions are described semantically using ontologies, thus specifying their interface in a machine-readable manner. Popular SWS approaches are OWL-S, WSMO, and SA-WSDL.

The Semantic Service Bus (SSB): is the key integration middleware in semantically enabled SOAs. Similar to an Enterprise Service Bus (ESB) it provides a communication and virtualization platform for services. In addition it introduces platform services fostering the use of semantic web techniques for data mediation, data transformation, process composition, discovery and reasoning. It provides a physically distributed but logically united entry point for semantic web services and semantic business processes and employs deployment strategies for such components.

Complete Chapter List

Search this Book: