bpmo requirements analysis and design

8/10/2019 BPMO Requirements Analysis and Design

1/36


2/36

Abstract

This deliverable is concerned with Semantic Business Process Management (abbrevi-ated as SBPM), especially its cornerstone Business Process Modeling Ontology (BPMO).

Basically, the document focuses on the requirements analysis and design of BPMO, whichis considered as the semantic description framework for business process in the SemBizproject. To determine the description requirements for business process management, weanalyze business use cases from the industrial partners and abstract a generalized processscenario. For realizing the determined requirement list, we propose the comprehensiveBPMO framework, and finally make it feasible with the extension of the semantic Webservice description framework WSMO. Although the main framework for BPMO has beendetermined, some details may be modified in the following period, based on the BPMO realimplementation with the use cases provided by the industrial partners.

2


3/36

List of Abbreviations

ARIS Architecture of Integrated Information Systems

ASM Abstract State MachineBPEL Business Process Execution Language

BPEL4WS Business Process Execution Language for Web Services

BPM Business Process Management

BPMI Business Process Modeling Initiative

BPML Business Process Modeling Language

BPMN Business Process Modeling Notation

BPMO Business Process Modeling Ontology

BPO Business Process Ontology

BPQL Business Process Query Language

BPR Business Process Reengineering

KIF Knowledge Interchange Format

OWL Web Ontology LanguageOWL-S OWL for Services

PSL Process Specification Language

SBPM Semantic Business Process Management

SESA Semantically-Enabled Service-oriented Architecture

SOA Service-Oriented Architecture

SWSF Semantic Web Services Framework

SWSI Semantic Web Services Initiative

SWSL Semantic Web Services Language

SWSO Semantic Web Services Ontology

UML Unified Modeling Language

WfMC Workflow Management Coalition

WS-CDL Web Service Choreography Description LanguageWSCI Web Service Choreography Interface

WSCL Web Service Conversation Language

WSDL Web Service Description Language

WSMF Web Service Modeling Framework

WSML Web Service Modeling Language

WSMO Web Service Modeling Ontology

WSMT Web Service Modeling Tool

WSMX Web Service Modeling eXecution environment

YAWL Yet Another Workflow Language

3


4/36

Contents

1 Introduction 3

1.1 Semantic Business Process Management . . . . . . . . . . . . . . . . . . . . . 3

1.2 Business Process Modeling Ontology . . . . . . . . . . . . . . . . . . . . . . 4

2 State-of-the-Art 5

2.1 Non-Semantic Process Modeling Approaches . . . . . . . . . . . . . . . . . . 5

2.1.1 Workflow, Business Process Reengineering and Management . . . . . . 5

2.1.2 Web Services, Service-Oriented Architecture (SOA) . . . . . . . . . . 6

2.2 Semantic Process Modeling Approaches . . . . . . . . . . . . . . . . . . . . . 8

2.2.1 Semantically-Enhanced Workflow Model . . . . . . . . . . . . . . . . 8

2.2.2 Semantic Business Process . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.3 Semantic Web Services, SESA . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Academic Foundations of Process Modeling . . . . . . . . . . . . . . . . . . . 10

2.3.1 Petri Net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.2 Abstract State Machine . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.3 Process Algebra, Pi-Calculus . . . . . . . . . . . . . . . . . . . . . . . 11

2.3.4 Temporal Logic, Transaction Logic . . . . . . . . . . . . . . . . . . . 11

2.3.5 AI Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Requirements Analysis for BPMO 13

3.1 Process Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 Process Description Requirements . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2.1 Concepts Involved in Business Processes . . . . . . . . . . . . . . . . 14

3.2.2 Functional Requirements for Process Description . . . . . . . . . . . . 16

3.2.3 Nonfunctional Requirements for Process Description . . . . . . . . . . 17

4 BPMO Design 19

4.1 Why Semantic Web Service for BPMO . . . . . . . . . . . . . . . . . . . . . 19

4.2 Why WSMO for BPMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.3 How to Extend WSMO for BPMO . . . . . . . . . . . . . . . . . . . . . . . . 25

4.3.1 Extension Highlights . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.3.2 BPMO UML Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.3.3 BPMO Element Definition . . . . . . . . . . . . . . . . . . . . . . . . 26

5 Conclusions and Future Steps 30


5/36

Outline

This outline is intended to partially integrate the index, giving the reader some additional

information on the content of the sections in such a way he could read only those parts relevantfor his specific purposes.

In the first section, a general introduction on Semantic Business Process Management (SBPM)

and its cornerstone Business Process Modeling Ontology (BPMO) is given. In the second

section, we provide an overview of the state of the art on business process modeling approaches

and their influence on the emerging semantically-enhanced business process management.

With the analysis of considered approaches and business scenarios presented, the third section

determines the description requirements for SBPM. The extension of Web Service Modeling

Ontology (WSMO) to realize BPMO will be addressed in the last main section of this deliver-

able based on the requirements previously extracted. Finally, we add some conclusive remarks

and future directions.

2


6/36

1 Introduction

In this section, we give a general introduction for the context of the SemBiz project, especially

the main idea of Semantic Business Process Management and its cornerstone Business ProcessModeling Ontology.

1.1 Semantic Business Process Management

Business Process Management (BPM) refers to managing IT-supported business operations

from a business experts perspective rather than from a technical perspective. Numerous tech-

nologies and tool suites are providing BPM support, ranging from graphical workflow design

tools to complex IT systems for automated execution support of business processes. However,

the degree of automation and support for the business experts perspective in existing BPM tech-

nologies is still very limited, which results in a gap between the business perspective and the

technical level for IT-supported business process execution. Therefore, in order to bridge the

gap between the business and the technical perspective, the SemBiz project (fully named Se-mantic Business Process Management for flexible dynamic value chains) proposes Semantic

Business Process Management (SBPM), which enables BPM by business people rather than IT

experts and allows scaling up to a new level of complexity in querying, discovery and compo-

sition of processes. Figure 1 gives an intuitional demonstration of the bridging-gap role of

SBPM between business level and technical level [23]

Figure 1: Idea of Semantically Enabled Business Process Management

To really bridge the gap between business perspective and technical perspective, SBPM in

the SemBiz project has the following objectives:

develop an exhaustive semantic description framework for business processes that allowsBPM by business experts on a higher level of abstraction as well as support for automated

handling and execution of business processes on the technical level;

develop semantically enabled core facilities for novel aspects of BPM that can be sup-ported by semantic descriptions, i.e.: browsing, editing, discovering, and composing se-

mantically described business processes;

develop a prototypical tool suite that utilizes the techniques developed for semanticallyenabled BPM and allows business experts to handle and manage business processes;

3


7/36

test and evaluate the usability and applicability of the developed tools in a real world usecase scenario in the telecommunication sector.

1.2 Business Process Modeling Ontology

From the previous general introduction of SBPM, we can realize that the sematic description

for business processes plays a crucial role in the whole SBPM proposal. In the SemBiz project,

one of the three main objectives is to define a semantic business process description framework,

named Business Process Modeling Ontology and abbreviated as BPMO. Basically, the BPMO

framework can be considered as the starting point and cornerstone for the SBPM vision.

The aim of BPMO is to define a precise and sufficient semantic description model for busi-

ness processes that encompasses business process description on a higher level of abstraction in

order to enable business level BPM facilities as well as connection to the technical implementa-

tion level for supporting automated execution of business processes. Ontologies shall be used as

the underlying data model in order to ensure semantic interoperability and advanced informa-

tion processing, meaning that all element descriptions as well as all information interchanged

are based on ontologies. Besides an adequate semantic description model for business processes

themselves, additional constructs are required for the BPMO with respect to the business level

BPM facilities to be supported: Goals and Queries as the underlying notions for semantically

enabled querying, discovery, and composition of business processes, and Mediators for han-

dling possibly occurring mismatches between business processes and other resources needed

for executing these. The detailed BPMO framework will be defined in the deliverable and im-

proved in the future period. Basically, there are at least following four core tasks for the BPMO

framework:

determine requirements of semantic business process descriptions;

define design strategies of BPMO;

determine specification languages for BPMO;

allow recursive definition and specification of the BPMO elements.

4


8/36

2 State-of-the-Art

In this section, we will briefly survey the state of the art of process modeling technologies,

including both non-semantic and semantic relevant approaches. There are many approachessupporting process modeling, referring to workflow and Web services. Besides the relevant

industrial standards, we further provide some concentration on the academic foundations for

process modeling.

Although providing a state of the art analysis is not one of this deliverables objective, we

consider that getting familiar with the current approaches is one of the pre-requisites in providing

a solid, well-documented set of requirements.

2.1 Non-Semantic Process Modeling Approaches

The focuses of traditional process modeling are pervasively on providing graphic-based tools

to design processes, such as Unified Modeling Language (UML) diagram, Business ProcessModeling Notation (BPMN) and Event-driven Process Chains (EPCs). Besides the graphical

modeling tools, language-based process description is another main focus, and in particular,

modeling language Business Process Modeling Language (BPML), querying language (BPQL)

and executing language (BPEL).

The graphical process modeling can be traced back to workflow, and then gradually evolve

into Business Process Reengineering (BPR) and Business Process Management (BPM); for the

description and execution of processes, several Web service approaches can be used as building

blocks, among which Business Process Execution Language for Web Services (BPEL4WS) is

one of the representatives. To fully support process interoperability, there are several studies

about web service cooperation, such as Web service choreography, orchestration and conversa-

tion.

2.1.1 Workflow, Business Process Reengineering and Management

About process modeling, traditional workflow technology has been researched for many years,

and gradually improved and evolved into business process reengineering and business process

management, which provides more powerful description capabilities and efficient process mod-

eling and management strategies.

Workflow

Workflow [52] has a long research history, which can be traced back to some office automa-

tion systems developed in 1970s, such as the emergence of SCOOP1 (developed by Michael

Zisman) and OfficeTalk2 (developed by Skip Ellis and Gary Nutt). In August 1993 the Work-flow Management Coalition (WfMC)3 was founded, aiming to standardize the process research,

including workflow and BPM. Workflow in WfMC is defined as:

1http://scoop.cim.com.au/2http://www.joops.com/3http://www.wfmc.org/

5


9/36

The automation of a business process, in whole or part, during which documents,

information or tasks are passed from one participant to another for action, accord-

ing to a set of procedural rules.

Furthermore, workflow management systems are responsible for defining, executing and

monitoring the workflow. The workflow patterns can be used for the analysis, comparison and

reuse of workflows. Aalst et al. have surveyed the patterns and assigned them to three categories

[51], i.e. control-flow patterns, data patterns and resource patterns.

Business Process Reengineering (BPR)

Different from workflow, BPR is further concerned with automating and re-engineering

existing works, which was yielded from the claim in the Harvard Business Review by Michael

Hammer in 1990 [21]. The claim was about companies focusing issues, which are not to

make non-value adding works but to automate and re-engineer existing works. Therefore,

BPR is a management approach aiming at improvements by means of elevating efficiency and

effectiveness of the processes that exist within and across organizations. Its a fundamental and

radical approach by either modifying or eliminating non-value adding activities. To achieve the

fully-fledged automation vision, many existing workflow techniques, especially process design,

can be reconsidered as the basis for process reengineering [25].

Business Process Management (BPM)

Besides process redesigning and automating, BPM is concerned with much more than work-

flow and BPR, such as the efficient design, quality documentation and the effective change

management. Howard Smith called BPM the third wave [48], which is not business-process

reengineering, enterprise application integration, workflow management or another packaged

application, but the synthesis and extension of all these technologies and techniques into a uni-

fied whole. Process modeling became more mature as the evolution from workflow to BPMtook place. The main difference between them is their perspectives: workflow is a purely tech-

nical perspective to model process flow, focusing on message sequences; whilst BPM pays

more attention on business perspective, to maximize enterprise efficiency and agility. Besides

the documentation (or message)-centric capability of workflow, BPM has a process-centric con-

trolling layer, to support higher-level integrations. BPM encompasses a robust Workflow, En-

terprise Application Integration (EAI), B2B integration and concepts such as Business Process

Re-engineering (BPR), Business Process Automation (BPA) and Business Process Integration

(BPI). In a nutshell, BPM is business-driven covering more than a set of process related tech-

nologies.

2.1.2 Web Services, Service-Oriented Architecture (SOA)

Web service research also provides some process modeling supports, especially some ground-

ing technologies. SOA further takes services as the building blocks for system integration

architecture for reusing and automating services in software engineering.

6


10/36

Web Services

A Web service is a service that is available over the web, supporting communication between

applications; the Web service technologies had significantly boosted the Web to dynamic Web.

A commonly-recognized definition of Web services is: Web service is a platform-independent,loosely coupled, self-contained web-enabled application, which is described, published, discov-

ered, coordinated and configured using XML artifacts for the purpose of developing distributed

interoperable applications [14]. There are three cornerstones for attaining interaction between

different programs: Simple Object Access Protocol (SOAP), Web Service Description Lan-

guage (WSDL) and Universal Description, Discovery, and Integration (UDDI). The three stan-

dards cornerstones are respectively taking charge of service communication protocol, service

description and service discovery.

For the process technologies like workflow and BPM, Web services play a crucial role, espe-

cially in the final process execution duration. Combined with Web services, BPM could become

a new breed of software automating processes both intra- and inter- enterprises. BPEL4WS

is a representative of such convergence, which becomes industrial and the de-facto standard for

business process execution. Thus, Web service can be seen as the building blocks for the processtechnologies in current industrial and academic process world. Some existing works on service

interoperability, such as service coordination, service conversation and service composition, can

further demonstrate the building block role of Web services for the process technologies. To ex-

press it more clearly, we briefly discuses the two kinds of service interoperation interfaces -

service orchestration and service choreography.

Orchestration provides a central process acting as the controller of several involved Web ser-

vices, and describes how those Web services can interact with each other to attain a more com-

prehensive and integrated service [4]. As mentioned, BPEL4WS has emerged as the de-facto

standard to define and manage business process activities and business interaction protocols for

collaborating Web services.

Choreography utilizes a set of message exchanging between the participating services toconsume a process [40]. There are several corresponding languages, such as Web Service

Choreography Language (WSCL)4 , Web Service Choreography Interface (WSCI)5 and Web

Service Choreography Description language (WS-CDL)6.

Service-Oriented Architecture (SOA)

SOA is a next evolutionary step for companies and allows both internal and external system

integration as well as the flexible reuse of application logic through the rearrangement of Web

services [37]. A common understanding of SOA is that it expresses a perspective of software

architecture that defines the use of loosely coupled software services to support the requirements

of the business processes and software users7. With the combination of BPM, SOA can get a

more business-enhanced perspective along the technical lines, aiming at a perfect combination

for enterprise computing [1]. BPM without SOA is useful for building applications, but difficult

to extend to the enterprise; SOA without BPM is useful for creating reusable and consistent

services, but lacks the ability to turn those services into an agile, competitive enterprise [8].

4http://www.w3.org/TR/wscl10/5http://www.w3.org/TR/wsci/6http://www.w3.org/TR/ws-cdl-10/7http://en.wikipedia.org/wiki/Service-oriented architecture

7


11/36

2.2 Semantic Process Modeling Approaches

Compared with so many non-semantic approaches for business processes, semantic process

methodologies are still in their infancy stage. In contrast to the previous section, we will discuss

the considered semantic approaches according to the reference division of workflows, business

processes and Web services.

2.2.1 Semantically-Enhanced Workflow Model

There is not much research on the semantically enhanced workflow model. Most of the works

focus on the semantic description or ontology extension of workflow. We will briefly address

two distinguish research projects and the Process Specification Language (PSL).

The projectm3pe8 is referring to workflow ontology extension, the goal of which is work-

flow interoperability: to understand, reason, and schedule workflows in different languages [19].

To attain such goal, there are two basic steps: first, to map from internal workflow models to the

intermediary formal mode; then, to generate choreography interfaces. Recently, the researcherson this project have further proposed m3po (multi meta-model process ontology) as the linking

ontology for internal and external business processes [20].

The NextGRID9 project, aims to develop the architecture for Next Generation Grids,

proposing a workflow-centric Grid Virtual Infrastructure Model. Based on OWL-S, a new on-

tology OWL-WS (OWL for Workflow and Services) is proposed to support semantic workflow

and Web service description [7].

Besides those workflow-based ontologies for individual projects, PSL [10] is intended to

be a commonly recognized process representation language that is pervasive to all business and

management applications, and powerful enough to represent the process in any given applica-

tions. To achieve this semantic interoperability, PSL acts as a modular, extensible first-order

logic ontology capturing concept requirements and business process specification. The PSL

ontology can be described by KIF (Knowledge Interface Format)10.

2.2.2 Semantic Business Process

To the best of our knowledge, there are two distinguished researches referring to semantic busi-

ness process ontology.

The first process ontology named BPO, from Karlsruhe AIFB11, aims to enhance Petri-net

process model with semantic descriptions, which can further facilitate process composition,

simulation and validation [29]. Processes modeled by Petri-Net and represented in the OWL

language, together with the background ontology modeled in UML and translated into OWL,

can be semantically aligned to support (semi-)automatic interconnectivity and reduce the com-

munication efforts [13].

The second process ontology called BPMO, a more comprehensive exisiting one, is the

considering ontology to realize SBPM, which combines semantic Web service technologies

8http://www.m3pe.org/9http://www.nextgrid.org/

10http://logic.stanford.edu/kif/dpans.html11http://www.aifb.uni-karlsruhe.de/Publikationen/Forschungsgebiete/viewForschungsgebietenglish?fgebiet id=124

8


12/36

(WSMO in particular) and BPM methodologies (especially ARIS12 - Architecture of Integrated

Information Systems) [23]. Through the analysis of relevant competency questions, the BPMO

ontology framework proposes a set of ontologies and formalisms, involving basic ontology UPO

(Upper-Level-Ontology) and three primary extension ones (sEPC Ontology, sBPMN Ontologyand sBPEL Ontology)[22] [24].

2.2.3 Semantic Web Services, SESA

Semantic Web services technology acts as an integrated approach combining semantic Web and

Web service, further realizing the vision of the next generation of Web [43]. This new Web

will be enhanced in both semantic and behavior level, and will achieve more intelligent and

automatic service. There are many considerable researches towards semantic Web services, and

we will briefly review the following four representatives.

WSMF: WSMO/WSML/WSMX

Web Service Modeling Framework (WSMF) was provided as a fully-fledged framework to

model semantic Web services [17]. To attain full potential of the web, from a collection of in-

formation into a distributed device of computation, WSMF gives two main principles (maximal

de-coupling complemented by scalable mediation service) and four elements (ontology, goal,

Web service and mediator) to model any aspects related with the services definition and usage.

To finally enable the framework, a set of corresponding technologies has been developed, such

as the modeling ontology WSMO 13 [45], the description language WSML 14 [16], and the

execution environment WSMX 15 [35].

OWL-S

Web Ontology Language for Web Services (OWL-S), part of the DAML Program16, spec-

ifies a set of ontologies based on OWL to describe different aspects of a semantic Web service[3]. There are three core ontologies, i.e. service profile,service model and grounding. Service

profile presents what a service does; service model describes how a service works ; service

grounding supports how to access it via detailed specifications of message formats, protocols

and so forth (normally expressed in WSDL). All the three ontologies are linked to the top-level

concept Service, which serves as an organization point of reference for declaring Web services;

the properties presents, describedBy, and supports of Service link to the above three core

ontologies respectively.

SWSF

Semantic Web Services Framework (SWSF) is a specification produced by the SWSL

Committee17

of the Semantic Web Service Initiative (SWSI). SWSF has its own conceptualmodel Semantic Web Service Ontology (SWSO) and relevant language Semantic Web Service

12http://www.pera.net/Methodologies/ARIS/ARIS Paper by Ted Williams.html13http://www.wsmo.org/14http://www.wsmo.org/wsml/15http://www.wsmx.org/16http://www.daml.org/17http://www.daml.org/services/swsl/

9


13/36

Language (SWSL). SWSO has been influenced by OWL-S and adopts its three ontologies, i.e.

service profile, model and grounding. The difference and the key contribution of SWSO are its

rich behavioral process model, based on PSL. With such extensions, SWSO can support more

powerful descriptions and reasoning on Web services. SWSL has two sub-sets, SWSL-FOLand SWSL-Rules, supporting first-order-logic and logic programming respectively [5].

WSDL-S

Web Service Description Language - Semantics (WSDL-S), developed by the Meteor-S

group at the LSDIS Lab 18, proposes a mechanism to augment WSDL with semantics, in par-

ticular focusing on the services functional descriptions. Based on the WSDL, WSDL-S has the

advantage of attaining semantics building on existing Web services; in the meantime, it does not

dictate a specific language for semantic description [6].

2.3 Academic Foundations of Process Modeling

During the previous section, we have discussed many different considered approaches and rele-

vant standards for process modeling, including both graphic-modeling tools and language-based

descriptions, considering non-semantic as well as semantic approaches. Besides industrial-

centric approaches, there are some formal techniques as the result of academic contribution.

In this section, we provide a concise introduction of those formal approaches and their rela-

tions to process modeling. For more detailed information, please refer to the related references

afterward.

2.3.1 Petri Net

Petri net, introduced by Carl Adam Petri in 1962 in his PhD thesis, is a promising tool for

describing and studying systems that are characterized as being concurrent, asynchronous, dis-tributed, parallel, nondeterministic, and/or stochastic [36]. Formally, a Petri net is a directed

bipartite graph with nodes (places and transitions) and arcs, which provides formal semantics

for further process analysis. In addition to the three basic elements (i.e. places, transitions, and

arcs) on classic Petri Nets, there are many extensions to get more powerful description capabil-

ity, like supporting color, time, hierarchy etc.

Due to the formal foundation for concurrency modeling, Petri nets are suitable for modeling,

simulating and analyzing business processes. On particular, its rather straightforward to model

workflow using Petri nets, and many research activities are focusing on this. Among those

researches, tasks are modeled by transitions, conditions are modeled by places, and cases are

modeled by tokens. Furthermore, many analysis techniques can be utilized in the analysis and

validation of processes. As discussed in Section 2.2.2, Petri net model is represented in the

OWL language to realize semantic business process ontology called BPO.

2.3.2 Abstract State Machine

Abstract State Machine, ASM for short, provides means to describe systems in an unambiguous

way using a semantically well founded mathematical notation. The core constituents are the

18http://lsdis.cs.uga.edu/projects/meteor-s/wsdl-s/

10


14/36

notation, the ground model technique and the refinement principle [18]. There are two main

categories in ASM, namely, Basic ASM and Multi-Agent ASM. Based on the minimality of

modeling primitive, the maximality of modeling expressive, and the formality, ASM has been

chosen as the underlying model for modeling WSMO interface, especially service choreography.

2.3.3 Process Algebra, Pi-Calculus

Process algebras, also called process calculi, are a family of approaches to formally model con-

current systems. Upon those models, it is possible to describe the interactions, communications

and synchronizations between processes [9]. With the development of process algebra, many

detailed algebras appear, such as CCS (Calculus of Communicating System), CSP (Communi-

cating Sequential Processes) and ACP (the Algebra of Communicating Processes). The most

recent addition to the process algebras family is pi-calculus, which was invented by Robin Mil-

ner as a formal language for concurrent computational processes. The pi-calculus provides a

framework for the representation, simulation, analysis and verification of mobile communica-

tion systems [47].

Recent results have shown that the pi-calculus is well suited for modeling classical work-

flows, also known as service orchestrations, as well as service choreographies that together form

a core foundation of future BPM [41] [46]. While most recent standards like BPEL, BPMN, or

WS-CDL only tackle the problem from a practical side, a formal foundation for BPM is still

missing. Pi-calculus has its own advantages to take charge of this role, as described in [32].

2.3.4 Temporal Logic, Transaction Logic

Some logic-based formalizations can also be used for process modeling, such as Temporal Logic

and Transaction Logic.

Temporal logic has been broadly used as a general logic for representing and reasoning abouttemporal information. Basically, temporal logic extends classical logic with modal operators

denoting a temporal modifier, such as the necessity operator and the possibility operator [34].

Temporal logic is also a formal approach for process modeling. For example, we can model

tasks in a process as: not executing, executing, done, aborted, and committed; events in a process

can be modeled as forcible, rejected and delayable. Additionally, temporal logic can be used for

process mining and verification [50].

Transaction Logic was developed by Anthony J. Bonner and Michael Kifer. It is an exten-

sion of predicate logic that accounts for state changes in databases and logic programs. Several

variants of transaction logic have been developed, which differentiate themselves by the expres-

sive power and computational complexity of the reasoning tasks [11]. Some approaches propose

using transaction logic for modeling, executing and reasoning on workflows (or processes), es-

pecially one of the extensions called currency transaction logic [27] [12].

2.3.5 AI Model

In [30], the authors present a formal framework for the representation of enterprise knowledge

with business processes. The framework is largely based on AI and its concepts (objectives and

11


15/36

goals, roles and actors, actions and processes, responsibilities and constraints) allowing business

analysts to capture enterprise knowledge in an intuitive and formal way.

An agent-based infrastructure for managing business processes was provided in [26],

demonstrating the key technologies of negotiating, service providing, autonomous agents, andfurther applying them in the British Telecom business process.

In addition to those generalized AI methodologies, there are some detailed algorithms for

process management, such as case-based reasoning for workflow model [33] and AI planning

for Web service composition [28]. Considering some formalization as the pre-requisites (such

as the planning domain, initial world, goals etc.), service composition can benefit from several

planning paradigms, such as state-based planning, graph-based planning, partial order refine-

ment, planning as satisfiablity, and planning as logic programming [28].

12


16/36

3 Requirements Analysis for BPMO

Considering the different process modeling approaches discussed in the state of the art, in this

section, we will focus on the requirement analysis for semantic business process descriptionBPMO, and in particular the extension mechanisms of WSMO to realize BPMO.

3.1 Process Scenario

For the requirement analysis for BPMO we have to consider not only the current state of the art

in process representation, but also to analyze process use cases in the some real-world applica-

tions. HANIVAL19 and eTel20 are the two industrial partners in the SemBiz project. HANIVAL

proposes an application scenario for business process within its own order-billing and provi-

sioning system for the chillydomains platform; eTel provides the Product Ordering use-case21. They both use popular graphic modeling techniques, like EPC or BPMN, to describe their

detailed process scenario. From these two scenarios we abstract the generalized scenario for

business process (shown in Figure 2). We can use this abstract scenario to analyze and de-rive the description requirements for semantic business processes, and finally develop BPMO

(Business Process Modeling Ontology).

As shown in Figure 2, the main and final aim of the scenario is to achieve a given business

goal. Firstly, the system tries to find the exact matching process for such a goal, and execute it

directly if exists. However, it is frequent that no such exact-matching business process exists for

the given goal. In this case, we have to decompose the goal into sub-goals, and query relevant

business processes for each sub-goal. We can loop this query procedure, until we reach an

indecomposable goal/sub-goal. If there are still no matching processes for this goal, we will

create a new process for the indecomposable goal, or adapt/modify existing processes. Finally,

according to the certain business logic and relevant business rules, we compose the relevant

business processes and invoke them at a certain sequence to achieve the whole business goalgiven before.

Although the above process scenario is abstract and simplified, many process description

requirements can be extracted. For process description requirements, we have the following two

obvious questions:

How to describe the business process to improve the soundness and efficiency of processdiscovery, composition and finally invocation?

How to describe the business goal, business rules and business logic to assist the invoca-tion of business process?

More inward and detailed requirements will be discussed in the next section.19http://www.hanival.net/20http://www.etel.at/21As we are still in an early phase of the project we consider these small application scenarios as our starting point,

but more complex scenarios will be analyzed as soon as they become available

13


17/36

Figure 2: Generalized Use Case Scenario for Business Processes

3.2 Process Description Requirements

By analyzing the real-world process use cases and the abstract process scenario, we will derive

the description requirements for the business processes modeling. Firstly, the involved concepts

will be overviewed and summarized; secondly, the functional description requirements will

be discussed; last but not least, some non-functional requirements for business processes are

proposed.

3.2.1 Concepts Involved in Business Processes

Requirement Engineering is a branch of software engineering which has many arbitrary tech-

niques to elicit the requirements before the system development [38]. The commonly recognized

first step is trying to define system boundaries, stakeholders, goals, and tasks etc. Hereby, to de-

termine the process descriptions requirements more completely, we apply relevant requirement

14


18/36

engineering techniques. We overview all the involved concepts in the whole business process

scenario, summarize them and provide relevant classification.

From the real-world use cases and the abstract scenario mentioned above, there are several

concepts involved: business goal, business rules, business process and business data. Basically,most information can be classified into two categories, i.e. business-related and process-related,

which are consistent with the two questions in Section 3.1.

Business-Related Concepts:

business goal: the final business objectives;

business rule (also called business logic): business rules are abstractions of the policiesand practices of a business organization, which affect the execution path for inter- or

intra- business processes; business rules can evaluate the data provided by the process

and control the basis for change in (business processes) flows;

business roles: to finally achieve the business goal, peoples (organization in enterprises),hardware (equipments or machines), or software (application programs) are involved in

the process execution, taking some responsibilities in executing the process;

business data: a lot of information is exchanged during the process scenario and relevantmodels are needed to describe them; generally, business data include business messages,

relevant events and time records, and all relevant document resources involved in the

whole business process lifecycle can be classified into and modeled with such concept.

Process-Related Concepts:

process component: the core element during the whole process scenario; the process canbe seen as a map of flow controls, which may be an un-dividable atomic activity or an

integrated one involving many sub-business processes/activities, decisions and loops;

process interaction: interaction is unavoidable during the process execution; we can dis-tinguish between two possible interaction modes: one is with business-related concepts

such as user interaction, and the other is with other business processes such as process

composition. For the sake of simplicity, we call the former interaction process interface

and the later one process interoperation

Basically, a fully-fledged description meta-model should be provided, which ought to con-

sider all the involved concepts, namely business goal, business role, business rule, business data,

process component and process interaction. We can infer the following main requirements refer-

ring to the involved concepts. To make the requirements more clear, we make the requirementslist and mark them with certain serial numbers. The following R1 and R2 will mainly focus on

the related concepts description requirements for the business process.

15


19/36

R1: The business-related concepts should be clear and concisely represented

As mentioned, there are four main concepts referring to the business, i.e. business goal,

business rule, business role, and business data. Accordingly, there are four sub-requirements to

concisely represent those business-related concepts.R1.1: Representation of the business goal;

the final aim for the execution of business processes.

R1.2: Representation of the business rules;

the business logic influencing the process execution, especially to make choices and provide

a logic sequential for process execution.

R1.3: Representation of the business role;

organization ontology, involving people, software, hardware.

R1.4: Representation of the business data;

all the relevant data involved in the whole life cycle of business process, such as documen-

tation, messages, events.

R2: The process-related concepts should be clear and concisely represented.

There are two main process-related concepts, i.e. the process itself and the process interac-

tion.

R2.1: Representation of the business process as a (or part of a) process component

We can classify business process as according to the granularity in the two categories. The

first one consists of atomic processes, i.e processes that can not be divided; the second category

consists of processes composed by other processes involving certain logical constructs such as

sequential, parallel, choice, loop, split, join etc. Furthermore, we can build upon those logic

constructs for business processes referring to the workflow patterns, especially control-flow

based patterns.

R2.2: Representation of the interaction requirements for business processes

There are two kinds of interactions: one is between business process and the involving busi-

ness role; the other is between processes themselves. The former can be compared to Web

service choreography, considering process interface interaction to invoke the process and attain

the goal from the process execution; the later can be compared to Web service orchestration,

considering process functionality composition to achieve integrated business processes. This

distinction is rather important only if we consider that a domain expert (human user) is go-

ing to be involved in the process execution. However, if we consider the automatic execution of

processes, it is not importantwhois actually interacting with the process, but only howthe inter-

action takes place, and from this point of view the business process execution is different from

the semantic Web service execution, and overall its description can be considered equivalentwith the description of a semantic Web service choreography.

3.2.2 Functional Requirements for Process Description

According to the definitions in requirement engineering, functional requirements specify spe-

cific behaviors of a system, involving the internal work on the software to finally realize the use

16


20/36

case [2]. With the above two kinds of concepts involved in the process scenario, most functional

requirements of process description can be determined and specified.

Taking the above concepts description requirements (R1 and R2) as the footstone, further

functional requirements are needed to describe the specific behavior of business processes. Fromthe business process use cases and abstract scenarios mentioned in section 3.1, there are three

main functional behaviors during the life cycle of business process, i.e. process discovery,

process composition and process invocation. Therefore, we will analyze the functional require-

ments for business process management according to this classification.

Process Discovery, Process Composition, Process Invocation:

R3: Functional descriptions needed for process discovery have to be included in process

specification

To query the matched processes for the goal/sub-goal, a certain match model between the

goal and the process is required. Basically the input/output parameters of the process are needed

to match the processes and the goal. On the meanwhile, a certain query language is needed tomatch processes and goals.

R3.1: Representation of the process query language

R3.2: Representation of matching between business goals

R3.3: Representation of matching between business process and business goal

R3.4: Representation of legacy process (how to re-describe existing processes modeled by

traditional methods, like EPC, BPMN etc.)

R4: Functional descriptions needed for process composition have to be included in pro-

cess specification

To match a complex goal, the relevant processes ought to be integrated together accordingto certain logic, such as concurrency, sequence or loop etc. Many workflow patterns and other

composition techniques can be refined for process composition.

R4.1: Representation of composition language, referring to R2.1integrated process

R5: Functional descriptions needed for process execution have to be included in process

specification

To finally achieve the business goal, processes should be invoked with certain grounding

technology. For example, Web services can be considered as the building blocks for final process

execution. Therefore, Web services should be wrapped and further described as the process

activities.

R5.1: Representation of grounding language, referring to BPEL4WS

3.2.3 Nonfunctional Requirements for Process Description

In addition to the functional requirements, there are also some non-functional requirements

playing important roles in software engineering. Typical non-functional requirements are some

17


21/36

specific criteria used to evaluate the quality of the system, such as the reliability, scalability, and

costs [15] [49].

To completely realize the business process, there are also some non-functional information

needed to be modeled, such as process quality and process compensation (the error port, thesubstitute for traditional ACID transaction, security, and reputation etc).

R6: Nonfunctional descriptions referring to the process quality have to be modeled

R7: Nonfunctional descriptions referring to the process security, robustness, and com-

pensation have to be modeled

There are broad description requirements for complete process modeling during the whole

process life cycle. In a nutshell, there are three main description requirements for BPMO,

i.e. the concepts involved in the business process life cycle, the functional requirements for

business process, and the non-functional requirements with additional process information to

assist successful business goal achievement.

18


22/36

4 BPMO Design

This section presents the initial design for Business Process Modeling Ontology. It starts with

an argumentation for using semantics for modeling business processes, and a justification forchoosing WSMO as the starting point for BPMO. It continues by presenting the relevant WSMO

concepts for BPMO, and by proposing several adjustments and modifications that would allow

the business process modeling.

4.1 Why Semantic Web Service for BPMO

With the survey on the various process modeling approaches and the analysis of the process de-

scription requirements discussed above, we argue for the importance of Web services to finally

achieve automatic process. In detailed, the Web service technologies can be considered as the

building blocks for business process, and in particular the final process execution. The objec-

tive involving semantics in Web services is to enable automatic service discovery, composition,

invocation, interoperation etc. In order to fulfill this objective, in [31] the authors provide a setof requirements for semantic Web services. Generally, business processes have similar require-

ments for automatic process discovery, composition, invocation, and monitoring. Therefore,

semantic Web services specification can be refined and enhanced for business processes, and

finally realize a semantic framework to describe business processes.

4.2 Why WSMO for BPMO

As discussed in Section 2.2.3, there are many existing semantic Web services approaches. How-

ever, we chose to use WSMO as the starting point for various reasons:

it is currently (one of) the most complete and consistent ontology for all semantic Webservices related aspects. WSMO consists of four main modeling elements, as presented

further in this section; the WSMO Web Service description constitutes the starting point

for process representation.

the representation language used by WSMO (WSML) allows the modeling of both se-mantic Web service capability and behavior, and from our initial investigations it can also

be used for representing any process related aspects. WSML is based on different logi-

cal formalisms, namely, Description Logics, First-Order Logic and Logic Programming,

and consists of a number of variants based on these different logical formalisms, namely

WSML-Core, WSML-DL, WSML-Flight, WSML-Rule and WSML-Full. For the first

version of BMPO we will use the WSML-Core variant as the simplicity for the imple-

mentation, which corresponds with the intersection of Description Logic and Horn Logic(without function symbols and without equality), extended with datatype support in order

to be useful in practical applications.

there exist already a reference implementation for WSMO, namely WSMX, which pro-vides a set of decoupled components with different functionalities, like discovery, media-

tion or invocation of SWS; WSMX can be considered our starting point in modeling the

BPMO Suite.

19


23/36

In the next subsection we will provide a brief overview of the Web Service Modeling On-

tology.

WSMO top Level Elements

Based on WSMF, WSMO proposes an overall framework for semantic Web services de-scription considering four top level elements, involving Ontologies, Web services, Mediators

and Goals (a graphical representation of the WSMO top level elements shown in Figure 3):

Ontologiesprovide the terminology used by other WSMO elements to describe the rele-vant aspects of the domains of discourse.

Goalsexpress the objectives that a client wants to achieve by invoking a Web service.

Web Servicesdescribe the computational entity providing access to services that providesome value in a domain. These descriptions comprise the capabilities, interfaces and

internal working of the Web service.

Mediatorsresolve the possible heterogeneity problems between the other elements.

Figure 3: WSMO four top level elements

WSMO refers to the set of concepts it defines as elements. The general definition of an ele-

ment is given in Listing 1. For presenting the following detailed WSMO elements definition, we

use the semantic Web service modeling language WSML, which provides the human readable

syntax.

Listing 1: WSMO Element Definition C l a s s wsmoElement

h a s A n n o t a t i o n t y p e a n n o t a t i o n

Annotations are entities used in defining the WSMO elements. The set recommended by

WSMO consists of most of the elements from [53], such as contributor,creator,date,descrip-

tion,identifier,language,publisher,source,title, etc.

Ontologies

Ontologies provide the terminology used by other WSMO elements to describe the relevant

aspects of the domains of discourse. Listing 2 depicts the WSMO definition of an ontology.

20


24/36

Listing 2: WSMO Ontology Definition

C l a s s o n t o l o g y su bC l a s s wsmoElementi m p o r t s O n t o l o g y t y p e o n t o l o g yu s e s M e d i a t o r t y p e o o M e d i a t o r

h a s C o n c e p t t y p e c o n c e p th a s R e l a t i o n t y p e r e l a t i o nh a s F u n c t i o n t y p e f u n c t i o nh a s I n s t a n c e t y p e i n s t a n c eh a s R e l a t i o n I n s t a n c e t y p e r e l a t i o n I n s t a n c ehasAxiom t y p e axiom

As ontologies can become quite complex, WSMO offers support for modularization. As

such, an ontology can import another ontology as long as no heterogeneity conflicts need to

be solved. If heterogeneity problems exists, an ooMediatorcan be used (more about WSMO

mediators can be found subsequently) to perform an alignment of the imported ontology.

In WSMO concepts represent the basic elements of the ontologies. A concept (Listing 3)

can contain attributes with names and types and it could be a sub-concept of other concepts (the

isArelation).

Listing 3: Concept Definition

C l a s s c o n c e p t su bC l a s s wsmoElementh a s S u p e r C o n c e p t t y p e c o n c e p th a s A t t r i b u t e t y p e a t t r i b u t eh a s D e f i n i t i o n t y p e l o g i c a l E x p r e s s i o n m u l t i p l i c i t y= s i n g l ev a l u e d

The attributes are defined as shown in Listing 4 and they can be filled at instance level.

The definition is a logical expression that can be used to formally describe the semantics of

the concept, i.e. the logical expression defines or restricts the extension (the instances) of this

concept.

Listing 4: Attribute Definition

C l a s s a t t r i b u t e su bC l a s s wsmoElementh a s R a n g e t y p e c o n c e p t m u l t i p l i c i t y= s i n g l ev a l u e d

In WSMO relations can be defined to model relationships between concepts, and by this

between their instances (Listing 5). A relation can be defined as being a sub-relation of one or

more relations, as having a given set of parameters and as being refined by a logical expression.

Listing 5: Relation Definition

C l a s s r e l a t i o n su bC l a s s wsmoElementh a s S u p e r R e l a t i o n t y p e r e l a t i o nh a s P a r a m e t e r t y p e p a r a m e t e rh a s D e f i n i t i o n t y p e l o g i c a l E x p r e s s i o n m u l t i p l i c i t y= s i n g l ev a l u e d

Accordingly, a parameter definition is given in Listing 6.

21


25/36

Listing 6: Parameter Definition

C l a s s p a r a m e t e r su bC l a s s wsmoElementhasDomai n t y p e c o n c e p t m u l t i p l i c i t y = s i n g l e v a l u e d

An instances of a WSMO concept has the form defined in Listing 7 where an attribute values

represents the value associated with a concepts attribute in the instance. The attribute values

(Listing 8) have to be defined in respect with the type declaration in the concept definition.

Listing 7: Instance Definition

C l a s s i n s t a n c e su bC l a s s wsmoElementh a s T y p e t y p e c o n c e p th a s A t t r i b u t e V a l u e s t y p e a t t r i b u t e V a l u e

Listing 8: Attribute Value Definition

C l a s s a t t r i b u t e V a l u e su bC l a s s wsmoElementh a s A t t r i b u t e t y p e a t t r i b u t e m u l t i p l i c i t y = s i n g l e v a l u e d h a s V a l u e t y p e { i n s t a n c e , l i t e r a l , a n o ny m ou s I d}

Similarly, one can define relation instances and parameters values, respectively (see Listing

9 and Listing 10).

Listing 9: Relation Instance Definition

C l a s s r e l a t i o n I n s t a n c e su bC l a s s wsmoElementh a s T y p e t y p e r e l a t i o nh a s P a r a m e t e r V a l u e t y p e p a r a m e t e r V a l u e

Listing 10: Parameter Value Definition C l a s s p a r a m e t e r V a l u e su bC l a s s wsmoElement

h a s P a r a m e t e r t y p e p a r a m e t e r m u l t i p l i c i t y = s i n g l e v a l u e d h a s V a l u e t y p e { i n s t a n c e , l i t e r a l , a n o ny m ou s I d}

m u l t i p l i c i t y = s i n g l e v a l u e d

The elements presented before correspond into the language to the so called conceptual syn-

tax. Additionally, one can refine its ontology by using axioms, which can constrain or logically

define the various aspects of the ontology (see Listing 11).

Listing 11: Axiom Definition

C l a s s axi om su bC l a s s wsmoElementh a s D e f i n i t i o n t y p e l o g i c a l E x p r e s s i o n

The logical expressions are used in the WSMO model to capture specific nuances of mean-

ing of modeling elements or their constituent parts in a formal and unambiguous way. More

details about the syntax of the formal language used for specifying the logical expressions can

be found in [44] while the semantics of this language is given in [16].

22


26/36

Web service

A Web Service description in WSMO is a description of both the functionality of the Web

service (as acapability) and its behavior (as an interface). Additionally, the description of the

Web service can also refer to a set of non-functional properties, to the set of ontologies modelingthe elements used in this descriptions (i.e. imported ontologies) and to the set of mediators the

service is referring to in order to address the heterogeneity problems (see Listing 12).

Listing 12: Web Service Description Definition

C l a s s w e b S e r v i c e su bC l a s s wsmoElementi m p o r t s O n t o l o g y t y p e o n t o l o g yu s e s M e d i a t o r t y p e {o o M e d i a t o r , w w Me d i at o r}h a s N o n F u n c t i o n a l P r o p e r t i e s t y p e n o n F u n c t i o na l P r o p e r t yh a s C a p a b i l i t y t y p e c a p a b i l i t y m u l t i p l i c i t y = s i n g l e v a l u e d h a s I n t e r f a c e t y p e i n t e r f a c e

Listing 13 defines the class used to describe the Web service specific non-functional prop-erties. WSMO does not pose restrictions of how the non-functional properties have to be en-

coded by logical expressions but such non-functional properties could include cost-related and

charging-related properties of a Web service [39], or properties like like accuracy, network-

related QoS, performance, reliability, robustness, scalability, security, etc [42].

Listing 13: Non-Functional Properties Definition

C l a s s n o n F u n c t i on a l P r o p e r t y su bC l a s s wsmoElementh a s D e f i n i t i o n t y p e l o g i c a l E x p r e s s i o n

The capability of a Web service is defined in terms of preconditions, assumptions, postcon-

dition and effects (Listing 14). The preconditions and assumptions define the information space

of the Web service and the state of the world, respectively, before execution while the postcon-

ditions and effects the information space of the Web service and of the world, respectively, after

the execution of the services.

Listing 14: Capability Definition

C l a s s c a p a b i l i t y su bC l a s s wsmoElementi m p o r t s O n t o l o g y t y p e o n t o l o g yu s e s M e d i a t o r t y p e {o o M e d i a t o r , w g M e d i a t o r}h a s N o n F u n c t i o n a l P r o p e r t i e s t y p e n o n F u n c t i o na l P r o p e r t yh a s S h a r e d V a r i a b l e s t y p e s h a r e d V a r i a b l e sh a s P r e c o n d i t i o n t y p e axiomh a s A s s u m p t i o n t y p e axi om

h a s P o s t c o n d i t i o n t y p e axiomh a s E f f e c t t y p e axi om

TheimportsOntology,usesMediatorandhasNonFunctionalPropertieshave the same mean-

ing as in the case of the Web service descriptions. The shared variables represent variables that

23


27/36

are shared between the preconditions, assumptions, postconditions and effects22.

The Web service interface is described in terms of the choreography and orchestration (List-

ing 15). The choreography of the service specifies how the requester should interact with the

service while the orchestration specifies how the service achieves its functionality by invokingother services.

Listing 15: Interface Definition

C l a s s i n t e r f a c e su bC l a s s wsmoElementi m p o r t s O n t o l o g y t y p e o n t o l o g yu s e s M e d i a t o r t y p e o o M e d i a t o rh a s N o n F u n c t i o n a l P r o p e r t i e s t y p e n o n F u n c t i o na l P r o p e r t yh a s C h o r e o g r a p h y t y p e c h o r e o g r a p h yh a s O r c h e s t r a t i o n t y p e o r c h e s t r a t i o n

Goals

TheGoaldescription (Listing 16) is similar with a Web Service description (WSMO treats

both the requestor and the provider of a goal as equal partners), containing a description of the

required capability (what the service should offer) and of the required interface (how the service

should be accessed).

Listing 16: Goal Definition

C l a s s g o a l su bC l a s s wsmoElementi m p o r t s O n t o l o g y t y p e o n t o l o g yu s e s M e d i a t o r t y p e {o o M e d ia t o r , g g M e d i a t o r}h a s N o n F u n c t i o n a l P r o p e r t i e s t y p e n o n F u n c t i o na l P r o p e r t yr e q u e s t s C a p a b i l i t y t y p e c a p a b i l i t y m u l t i p l i c i t y = s i n g l e v a l u e d r e q u e s t s I n t e r f a c e t y p e i n t e r f a c e

Having similar descriptions for the services and the service request facilitate the Web ser-

vices discovery by a potential client, the selection of the most appropriate service for a certain

task, the actual invocation of a service and the composition of multiple services for accomplish-

ing a common task.

Mediators

The WSMO mediators are mechanisms for getting different systems to work together, to

agree on the format of messages exchanged and protocols/processes used. WSMO defines me-

diators (see Listing 17) between two ontologies (ooMediators), two services (wwMediators),

two goals (ggMediators) and a requestor and a provider of a service (wgMediators).

22If ?v1,...,?vn are the shared variables defined in a capability, and pre(?v1,...,?vn),

ass(?v1,...,?vn), post(?v1,...,?vn)and eff(?v1,...,?vn)are used to denote the formulae de-

fined by the preconditions, assumptions, postconditions, and effects respectively, then the following holds:

forAll ?v1,...,?vn (pre(?v1,...,?vn)and ass(?v1,...,?vn)

impliespost(?v1,...,?vn)and eff(?v1,...,?vn)).

24


28/36

Listing 17: WSMO Mediators Definition

C l a s s m e d i a t o r su bC l a s s wsmoElementi m p o r t s O n t o l o g y t y p e o n t o l o g yh a s N o n F u n c t i o n a l P r o p e r t i e s t y p e n o n F u n c t i o na l P r o p e r t y

h a s S o u r c e t y p e { o n t ol o g y , g o a l , w e bS e r vi c e , m e d i a t o r}h a s T a r g e t t y p e { o n t ol o g y , g o a l , w e bS e r vi c e , m e d i a t o r}h a s M e d i a t i o n S e r v i c e t y p e {g o a l , w e b S e r vi c e , w wM e di at or}

C l a s s o o M e d i a t o r su bC l a s s m e d i a t o rh a s S o u r c e t y p e { o n t o l o g y , o o M e d i a t o r}

C l a s s g g M e d i a t o r su bC l a s s m e d i a t o ru s e s M e d i a t o r t y p e o o M e d i a t o rh a s S o u r c e t y p e {g o a l , g g M e d i a t o r}h a s T a r g e t t y p e {g o a l , g g M e d i a t o r}

C l a s s wgMedi at or su bC l a s s m e d i a t o ru s e s M e d i a t o r t y p e o o M e d i a t o rh a s S o u r c e t y p e {w e b S e r vi c e , g o a l , w g Me d ia t or , g g M e d i a t o r}h a s T a r g e t t y p e {w e b S e r vi c e , g o a l , g g M e d ia t o r , w g M ed i a to r}

C l a s s wwMediator su bC l a s s m e d i a t o ru s e s M e d i a t o r t y p e o o M e d i a t o rh a s S o u r c e t y p e {w e b S e r v i c e , w w Me d i at o r}h a s T a r g e t t y p e {w e b S e r v i c e , w w Me d i at o r}

4.3 How to Extend WSMO for BPMO

Starting with WSMO, we will provide some modification and extension for modeling business

process.

4.3.1 Extension Highlights

In this section, we will present the main extension strategies of WSMO for BPMO, involving

the similar and the distinguished characteristics of BPMO. Generally, there are the following

extension highlights:

The four main high-level elements in WSMO, i.e. ontology, Web service, goal, mediator,can be significantly reused in BPMO, respectively as ontology, business process, business

goal, and mediator.

For BPMO ontology, the WSMO ontology definition provides almost the concept neededin representing a process. The distinguish point hereby is that we should emphasis the de-

tailed concepts involving in the business process scenario, involving business rule, busi-

ness role, and business data, in consistent with the description requirements R1.2, R1.3,

andR1.4.

The BPMO business process is similar with WSMO Web service; one difference is that

we accept only one type of mediators, the ontology-to-ontology mediator; another maindifference is we use execution instead of interface for business process. The main reason

is that, in the business processes environment, we are more concerned with how the pro-

cess is actually executed, and not with how it can be invoked or with how it can orchestrate

other services. These operations are going to be handled by specialized components in

the BPM Suite [54].

25


29/36

For BPMO business goal, like WSMO goal, BPMO uses it to express the business objec-tives that can be achieved by executing business processes. Unlike the WSMO goals, the

BPMO goals do not have a dedicated interface, as the requester is not aware of how the

process is executed. For BPMO mediator, unlike WSMO, BPMO does not consider the need of mediating be-

tween any two entities. Only ontology-to-ontology mediator is considered in the Sembiz

project.

Different from Non-functional-properties in WSMO, which acts as special properties to-gether with the four elements, BPMO provides a more separate mode for NFP according

to the more complex non-functional requirements.

4.3.2 BPMO UML Diagram

To make the framework clearer and provide a basis for the BPMO implementation, we propose

a comprehensive UML diagram involving all the BPMO elements, as shown in Figure 4. Thecurrent diagram is still in its infancy, and will be improved and refined in our future works.

Figure 4: BPMO Elements UML Diagram

Basically, there are five core elements inheriting from the fundamental element BPMOEle-

ment, which can be inherited from WSMOElement. Therefore, all the existing description prop-

erties in WSMO can be reused in the BPMO framework.

4.3.3 BPMO Element Definition

As mentioned, BPMO can be inherited from WSMO as reusing many existing features from

semantic Web service description (see Listing 18).

Listing 18: BPMO element Definition C l a s s bpmoEl ement su bC l a s s wsmoElement

26


30/36

Ontology

Like the role of ontology in WSMO, for BPM we need the support of ontologies for model-

ing all the concepts needed in representing a process. For now, the WSMO ontologies provide

almost all the modeling elements BPMO need. However, what we want to emphasis here is thebusiness-related concepts involved in the business process scenario (see Listing 19).

Listing 19: BPMO ontology Definition

C l a s s o n t o l o g y su bC l a s s bpmoElementi m p o r t s O n t o l o g y t y p e o n t o l o g yu s e s M e d i a t o r t y p e o o M e d i a t o rh a s C o n c e p t t y p e c o n c e p th a s R e l a t i o n t y p e r e l a t i o nh a s F u n c t i o n t y p e f u n c t i o nh a s I n s t a n c e t y p e i n s t a n c eh a s R e l a t i o n I n s t a n c e t y p e r e l a t i o n I n s t a n c ehasAxiom t y p e axiom

C l a s s b u s i n e s s R u l e su b

C l a s s o n t o l o g y/ / e x p r e s s e d a s ax i om or f u n c t i o n/ / e x p r e s s e d a s ASM r u l e s

C l a s s b u s i n e s s R o l e su bC l a s s o n t o l o g y/ / s p e c i f i c b u s i n e s s o r g a n i z a t i o n o n t o l o g y , r o l e s an d t a s k s

C l a s s b u s i n e s s D a t a su bC l a s s o n t o l o g y/ / s p e c i f i c b u s i n e s s d a t a ( m e s s ag e s , do c um e nt s , e v e n t s , t i m e , )/ / an d l o g i n f o r m a t i o n i n v o l v e d i n t h e w ho l e BPM l i f e c y c l e

Business Processes

The definition of a business process is very similar with the definition of Web Services, from

the Web Service modeling Ontology, and is presented in List(see Listing 20).

Listing 20: BPMO businessProcess Definition

C l a s s b u s i n e s s P r o c e s s su bC l a s s bpmoElementi m p o r t s O n t o l o g y t y p e o n t o l o g yu s e s M e d i a t o r t y p e o o M e d i a t o rh a s N o n F u n c t i o n a l P r o p e r t i e s t y p e n o n F u n c t i o na l P r o p e r t yh a s C a p a b i l i t y t y p e c a p a b i l i t y m u l t i p l i c i t y = s i n g l e v a l u e d h a s E x e c u t i o n t y p e e x e c u t i o n

C l a s s c a p a b i l i t y su bC l a s s bpmoEl ementi m p o r t s O n t o l o g y t y p e o n t o l o g yu s e s M e d i a t o r t y p e o o M e d i a t o rh a s N o n F u n c t i o n a l P r o p e r t i e s t y p e n o n F u n c t i o na l P r o p e r t yh a s S h a r e d V a r i a b l e s t y p e s h a r e d V a r i a b l e sh a s P r e c o n d i t i o n t y p e axiom

h a s A s s u m p t i o n t y p e axi omh a s P o s t c o n d i t i o n t y p e axiomh a s E f f e c t t y p e axi om

C l a s s e x e c u t i o n su bC l a s s bpmoEl ementh a s N o n F u n c t i o n a l P r o p e r t i e s t y p e n o n F u n c t i o n a l P r o p e r t i e sh a s S t a t e S i g n a t u r e t y p e s t a t e S i g n a t u r eh a s S t a t e t y p e s t a t eh a s T r a n s i t i o n R u l e s t y p e t r a n s i t i o n R u l e s

27


31/36

Non-Functional Properties

Non-functional properties needed for the Business Process modeling additionally include In

WSMO, non-functional issues usually are modeled with the four elements as special properties.

For BPMO, according to the more complex non-functional requirements, relevant informationneeds to be modeled in more separate mode. There are four major non-functional issues that

should be emphasized in process modeling. Process compensation should be considered as

the substitution of the ACID transaction requirement in traditional database systems; QoS of

process can make high-quality process available; security is always the primary precondition for

the business community; process logs are the valuable information sources to support process

monitoring and process mining, and the process improvement finally (see Listing 21).

Listing 21: BPMO nonFunctionalProperties Definition

C l a s s n o n F u n c t i o n a l P r o p e r t i e s su bC l a s s bpmoElementh a s C o n t r i b u t o r t y p e d c : c o n t r i b u t o rh a s C o v e r a g e t y p e d c : c o v e r a g e

h a s C r e a t o r t y p e d c : c r e a t o rh a s D a t e t y p e d c : d a t eh a s D e s c r i p t i o n t y p e d c : d e s c r i p t i o nh a s F o r m a t t y p e d c : f o r m a th a s I d e n t i f i e r t y p e dc : i d e n t i f i e rh a s L a n g u a g e t y p e d c : l a n g u a g ehasOwner t y p e ownerh a s P u b l i s h e r t y p e d c : p u b l i s h e rh a s R e l a t i o n t y p e d c : r e l a t i o nh a s R i g h t s t y p e d c : r i g h t sh a s S o u r c e t y p e d c : s o u r c eh a s S u b j e c t t y p e d c : s u b j e c th a s T i t l e t y p e dc : t i t l eh a s T y p e t y p e dc :t y p eh a s V e r s i o n t y p e v e r s i o

h a s C o m p e n s a t i o n t y p e C o m p e n s a t i o n

h a s Q u a l i t y t y p e Q u a l i t yh a s S e c u r i t y t y p e S e c u r i t yhasLog t y p e Log

Business Goal

Like goals in WSMO, BPMO uses goals to express the business objectives that can be

achieved by executing business processes. Goals can be considered as specific business pro-

cesses that would potentially satisfy the user desires. Unlike the WSMO goals, the Business

goals do not have a dedicated interface - we care only what the requirement is in terms of the

required functionality and not in terms of the required behavior (or in other words, the requester

is not interested in how the process is executed, see Listing 22).

Listing 22: BPMO businessGoal Definition

C l a s s b u s i n e s s G o a l su bC l a s s bpmoElementu s e s M e d i a t o r t y p e o o M e d i a t o rh a s N o n F u n c t i o n a l P r o p e r t i e s t y p e n o n F u n c t i o na l P r o p e r t yh a s C a p a b i l i t y t y p e c a p a b i l i t y m u l t i p l i c i t y = s i n g l e v a l u e d

28


32/36

Mediator

We acknowledge the importance of mediators in a semantic environment, as defined by

Web Service Modeling Ontology, but unlike WSMO we do not consider the need of mediating

between any two entities. The ontologies used for modeling different processes or processrequests may differ, so we adopt the WSMO definition of ooMediator (see Listing 23). However,

the other three types of WSMo mediators are not beeded for BPMO, their functionality being

covered by several components from BPM Suite [48]

Listing 23: BPMO mediator Definition

C l a s s m e d i a t o r su bC l a s s bpmoElementi m p o r t s O n t o l o g y t y p e o n t o l o g yh a s N o n F u n c t i o n a l P r o p e r t i e s t y p e n o n F u n c t i o na l P r o p e r t yh a s S o u r c e t y p e { o n t o l o g y}h a s T a r g e t t y p e { o n t o l o g y}h a s M e d i a t i o n S e r v i c e t y p e {g oa l , p r o c e s s}

29


33/36

5 Conclusions and Future Steps

At the beginning of this deliverable, we briefly overview the state of the art of process mod-

eling approaches, including non-semantic and semantic ones, and considering both industrialstandards and formal theoretical foundations. After the survey, together with the starting point

of business process real use cases and abstracted scenarios, we determine the description re-

quirements of semantic business process. Finally, we present the feasible WSMO extension

to design BPMO, aiming at the achievement of comprehensive description framework for the

above determined semantic description requirements.

The next steps will be the detailed design of all the BPMO elements for the actual implemen-

tation. As previously stated in this document, we will reuse already existing WSMO framework

and its description language WSML, adapting them to suit the business process scenario in the

SemBiz project.

References

[1] Business process management on an soa foundation, a unified framework for process de-

sign and deployment. http://www.tibco.com/resources/solutions/soa/bpm-soa.pdf.

[2] Functional requirement. http://en.wikipedia.org/wiki/Functional requirements.

[3] Owl-s 1.2 release. Available from http://www.daml.org/services/owl-s/1.0/.

[4] Web service choreography. http://citeseer.ist.psu.edu/kobayashi03typebased.html, 2002.

[5] Semantic web service framework, swsf version 1.0. SWSF Available from

http://www.daml.org/services/swsf/1.0/, 2005.

[6] R. Akkiraju, J. Farrell, J. Miller, M. Nagarajan, M. Schmidt, A. Sheth, and

K. Verma. Web service semantics - wsdl-s. Technical note Available from

http://lsdis.cs.uga.edu/library/download/WSDL-S-V1.html, April 2005.

[7] S. Beco, B. Cantalupo, L. Giammarino, N. Matskanis, and M. Surridge. Owl-ws: A work-

flow ontology for dynamic grid service composition. In E-SCIENCE 05: Proceedings

of the First International Conference on e-Science and Grid Computing , pages 148155,

Washington, DC, USA, 2005. IEEE Computer Society.

[8] G. K. Behara. Bpm and soa: A strategic alliance. BPTrends,

http://devresource.hp.com/drc/technical white papers/WSOrch/WSOrchestration.pdf,

May 2006.

[9] J. Bergstra, A. Ponse, and S. Smolka. Handbook of Process Algebra. Elsevier ScienceInc., 2001.

[10] C. Bock and M. Gruninger. Psl: A semantic domain for flow models.Software and Systems

Modeling Journal, pages 209231, 2005.

[11] A. J. Bonner and M. Kifer. Transaction logic programming. InInternational Conference

on Logic Programming, pages 257279, 1993.


34/36

[12] A. J. Bonner and M. Kifer. Concurrency and communication in transaction logic. InJoint

International Conference and Symposium on Logic Programming, pages 142156, 1996.

[13] S. Brockmans, M. Ehrig, A. Koschmider, A. Oberweis, and R. Studer. Semantic alignment

of business processes. InICEIS (3), pages 191196, 2006.

[14] E. Cerami. Web Services Essentials, Distributed Applications with XML-RPC, SOAP,

UDDI and WSDL. OReilly, 2002.

[15] L. Chung, B. A. Nixon, and E. Yu.Non-Functional Requirements in Software Engineering.

Springer, 1999.

[16] J. de Bruijn. D16 the wsml specification. WSMO Deliverable available from

http://www.wsmo.org/TR/d16/, February 2005.

[17] D. Fensel and C. Bussler. The web service modeling framework wsmf. Electronic Com-

merce Research and Applications, pages 209231, 2002.

[18] E. Groger and R. Stark.Abstract State Machine - A Method for High-Level System Design

and Analysis. Springer, 2002.

[19] A. Haller and E. Oren. m3pl: A work-flows ontology extension to extract choreography

interfaces. InIn Proceedings of the Workshop on Semantics for Business Process Manage-

ment Workshop at ESWC2006, Budva, Montenegro, 2006.

[20] A. Haller, E. Oren, and P. Kotinurmi. m3po: An ontology to relate choreography mod-

els to workflow models. InIn Proceedings of the International Conference on Services

Computing (SCC 2006), Chicago, Illinois, 2006.

[21] M. Hammer. Re-engineering work: Dont automate, obliterate.Harvard Business Review,

pages 104112, 1990.

[22] M. Hepp. Super deliverable1.1 process modeling ontology and mapping to wsmo.

http://www.ip-super.org/, 2006.

[23] M. Hepp, F. Leymann, J. Domingue, A. Wahler, and D. Fensel. Semantic business process

management: A vision towards using semantic web services for business process manage-

ment. InIEEE International Conference on e-Business Engineering (ICEBE 2005) , pages

535540, Beijing, China, October 2005.

[24] M. Hepp, F. Leymann, J. Domingue, A. Wahler, and D. Fensel. An ontology framework

for semantic business process management. In Proceedings of Wirtschaftsinformatik 2007,

Karlsruhe, Germany, February 2007.

[25] Z. Irani, V. Hlupic, and G. Giaglis. Business process re-engineering: A modeling perspec-

tive. International Journal of Flexible Manufacturing Systems, 12(4):247252, 2000.

[26] N. Jennings, P.Faratin, M. Johnson, T. Norman, P.OBrien, and M. Wiegand. Agent-based

business process management. International Journal of Cooperative Information Systems,

5(2&3):105130, 1996.

31


35/36

[27] M. Kifer. Transaction logic for the busy workflow professional, 1996.

[28] M. Kifer. Web service composition as ai planning - a survey, 2005.

[29] A. Koschmider and A. Oberweis. Modeling semantic business process models. AIFB-Karlsruhe, 2006.

[30] M. Koubarakis and D. Plexousakis. Business process modeling and design: Ai models and

methodology, 1999.

[31] R. Lara, H. Lausen, S. Arroyo, J. de Bruijn, and D. Fensel. Semantic web services: De-

scription requirements and current technologies. In In International Workshop on Elec-

tronic Commerce, Agents, and Semantic Web Services, September 2003.

[32] R. Lucchi and M. Mazzara. A pi-calculus based semantics for ws-bpel. Journal of Logic

and Algebraic Programming.

[33] T. Madhusudan, J. L. Zhao, and B. Marshall. A case-based reasoning framework for

workflow model management. Data Knowledge Engineering, 50(1):87115, 2004.

[34] Z. Manna and A. Pnueli. The Temporal Logic of Reactive and Concurrent Systems: Spec-

ification. Springer, 1991.

[35] A. Mocan, M. Moran, E. Cimpian, and M. Zaremba. Filling the gap - extending service

oriented architectures with semantics. In EEE International Conference on e-Business

Engineering 2006 (ICEBE 2006), pages 594601, Shanghai, China, October 2006.

[36] T. Murata. Petri nets: Properties, analysis and applications. In roceedings of the IEEE,

Vol. 77, No. 4, pages 541580, April 1989.

[37] E. Newcomer and G. Lomow. Understanding SOA with Web Services. Addison Wesley

Professional, December 2004.

[38] B. Nuseibeh and S. Easterbrook. Requirements engineering: a roadmap. In ICSE 00:

Proceedings of the Conference on The Future of Software Engineering , pages 3546, New

York, NY, USA, 2000. ACM Press.

[39] J. OSullivan, D. Edmond, and A. T. Hofstede. Whats in a service? towards accurate

description of non-functional service properties. Distributed Parallel Databases, 12(2-

3):117133, 2002.

[40] C. Peltz and H. Packard. Web service orchestration, a review of emerging technolo-

gies, tools, and standards. http://devresource.hp.com/drc/technical white papers/WSOrch/

WSOrchestration.pdf, January 2003.

[41] F. Puhlmann and M. Weske. Using the i-calculus for formalizing workflow patterns. In

Business Process Management, pages 153168, 2005.

[42] S. Rajesh and D. Arulazi. Quality of service for web

services-demystification, limitations, and best practices. See

http://www.developer.com/services/article.php/2027911 , March

2003.

32


36/36

[43] D. Roman, J. de Bruijn, A. Mocan, I. Toma, H. Lausen, J. Kopecky, C. Bussler, D. Fensel,

J. Domingue, S. Galizia, and L. Cabral. Semantic Web Technologies, trends and research

in ontology-based systems, chapter Semantic Web Service - Approaches and Perspectives.

WILEY, 2006.[44] D. Roman, H. Lausen, and U. K. (eds.). D2v1.3 Web Service Mod-

eling Ontology (WSMO). Technical report, WSMO Final Draft,

http://www.wsmo.org/TR/d2/v1.3/ , October 2006.

[45] D. Roman, H. Lausen, and U. Keller. D2v1.3. web service modeling ontology (wsmo).

WSMO Deliverable available from http://www.wsmo.org/TR/d2/v1.3/, Octomber 2006.

[46] S. Ross-Talbot. Web services choreography and process algebra.

http://www.daml.org/services/swsl/materials/WS-CDL.pdf, 2004.

[47] D. Sangiorgi and D. Walker. The Pi-calculus - A Theory of Mobile Processes. Cambridge

University Press, 2004.

[48] H. Smith and P. Fingar. Business Process Management: The Third Wave. Meghan-Kiffer

Press, Tampa, FL, USA, 2002.

[49] I. Toma and D. Foxvog. D28.4v0.1 non-functional properties in web services. WSMO

Deliverable, available from http://www.wsmo.org/TR/d28/d28.4/v0.1/, October 2006.

[50] W. van der Aalst, H. de Beer, and B. F. van Dongen. Process mining and verification of

properties: An approach based on temporal logic. In OTM Conferences (1), pages 130

147, 2005.

[51] W. van der Aalst, A. ter Hofstede, B.Kiepuszewski, and A.P.Barros. Workflow patterns.

Distrib. Parallel Databases, 14(1):551, 2003.

[52] W. van der Aalst and K. van Hee. Workflow Management: Models, Methods, and Systems.

MIT Press, 2002.

[53] S. Weibel, J. Kunze, C. Lagoze, and M. Wolf. RFC 2413 - Dublin Core Metadata for

Resource Discovery, September 1998.

[54] Z. Yan, E. Cimpian, M. Mazzara, and M. Zaremba. D3.1 sembiz bpmsuite requirements

analysis and design. SemBiz Deliverable, February 2007.

bpmo requirements analysis and design

Documents