-semantic_reengineering_of_business_processes.pdf
DESCRIPTION
Semantic_reengineeringTRANSCRIPT
ARTICLE IN PRESS
Contents lists available at ScienceDirect
Information Systems
Information Systems 35 (2010) 496–504
0306-43
doi:10.1
� Tel.
E-m
journal homepage: www.elsevier.com/locate/infosys
Semantic reengineering of business processes
Violeta Damjanovic �
Salzburg Research Forschungsgesellschaft, Knowledge based IS, Jakob Haringer Strasse 5-II, 5020 Salzburg, Austria
a r t i c l e i n f o
Keywords:
Business process modelling
Model transformations
Process algebra
Model-driven architecture
79/$ - see front matter & 2009 Elsevier B.V. A
016/j.is.2009.06.003
: +43 699 10955020.
ail address: violeta.damjanovic@salzburgresea
Downloaded from http://www.elearn
a b s t r a c t
This paper discusses transforming ontological models into non-ontological models of
business processes, when the process of articulating different data models is known as
reengineering domains. As a crucial factor in achieving interoperability and semantic
reengineering of the domains with the different levels of semantic representation
(expressiveness), we point out the role of foundational ontology that serves to enable
global meaning of the process knowledge and that is, in this paper, additionally
connected with the process theory (process algebra). The main focus of the process
theory is on the system that interacts with one another, such as the business processes,
whereas the main idea of semantic reengineering is transforming ontological models
into the semantic business processes that can be (semi-)automatically executed via a
workflow engine. Therefore, as a promising solution in achieving interoperability
between the real enterprise needs and the business process models, we involve the
Pi-Calculus as a process theory to provide semantics between the ontological models
based on the DOLCE Description and Situation (D&S) Plan and Tasks Ontology (DDPO)
and the business process models that are expressed in Business Process Execution
Language (BPEL).
& 2009 Elsevier B.V. All rights reserved.
1. Introduction
The future business process domains will be certainlygrounded in ontological knowledge with the ability toreuse existing knowledge, articulate the new businessprocesses based on them and provide ontological explica-tion of activities, steps and procedures involved increating software solutions for the business processes.In this paper, we use the DOLCE Description and Situation(D&S) Plan and Tasks Ontology (DDPO) model as asemantic data model to help us get a good understandingof the task and plan models and provide implicit rules forconcepts that explain behaviour as well as structure ofboth executable and abstract business processes. In otherwords, we use the main DDPO ontological concepts such
ll rights reserved.
rch.at
ica.ir
as non-physical, social, non-agentive [1] for representingthe process knowledge.
Nowadays, for the sake of combining the ontologicalresources with the non-ontological resources such asbusiness processes, new tools and methods to supportprocess knowledge creation are needed. Hence, wepropose semantic reengineering of the ontological knowl-edge domains to semantically support (semi-)automaticcreation of business processes via process knowledgethat is additionally expressed in the form of Pi-Calculus.Our approach also builds on related work in this areaconnecting ontologies and business processes, such as [2]that describes an ontology for executable businessprocesses using the formalism of the Web ServiceModelling Language (WSML); [3] that proposes a set ofontologies and formalisms, and defines the scope of theseontologies by giving competency questions that is acommon approach in the ontology engineering; [4] thatexplores the behavioural aspects of Web services and
ARTICLE IN PRESS
V. Damjanovic / Information Systems 35 (2010) 496–504 497
proposes using Description Logics (DL) for their formali-zation.
As the main motivation of this paper, we address theproblem of exchanging the information between thesemantic data models (based on the DDPO and expressedin Web Ontology Language (OWL)) and the real businessmodels (expressed in Business Process ExecutionLanguage (BPEL)). The business processes from thedomain of mechatronic engineering are chosen to ex-plicate the main challenges in semantic reengineering ofbusiness processes.
Table 1The syntax of the DDPO theoretical model: basic concepts and relations
[6].
Syntax of the DDPO theoreticalmodel
Semantics
Plan(x)-Description(x) Plan is a description of x
Plan(x)-(t. Task(t) 4Uses(x,t) y that uses at least one task ty
Plan(x)-(c. ((AgentiveRole(c)
3Figure (c)) 4Uses(x,c)
y and at least one agentive role c
or Figure cy
Plan(x)-(g. Goal(g)
4ProperPart(x,g)
y and that has at least one goal g
as a proper part
Subplan(x) ¼ df Plan(x) 4(y.
Plan(y) 4ProperPart(y,x)
A subplan x can have varied
proper parts, including other
plans y
Goal(x) ¼ df Desire(x) 4(p.
Plan(p) 4A goal x is defined as a desire that
is a proper part of a plan p
ProperPart(p,x)
PlanExecution(x) ¼ df
Situation(x) 4(y. Plan(y) 4P-
SAT(x,y)
Plan execution (execution of a
plan x) is defined as a situation
that proactively satisfy a plan y
(P-SAT)
GoalSituation(x) ¼ df
Situation(x) 4(y. Goal(y)
4SAT(x,y)
A goal situation x is defined as a
situation that satisfy a goal y
GoalSituation(x)-8y,p,s. (Goal(y)
4SAT(x,y) 4Plan(p)
4ProperPart(p,y) 4P-SAT(s,p))-
:ProperPart(s,x)
A goal situation x is not a proper
part of the execution of a plan x
Precondition(p,s)-Plan(p)
4Situation(s)
A precondition for a plan p can be
defined as a relation between a
situation s and a plan p, implying
that for all plan executions of
that plan to occur, a situation
should preliminary satisfy some
description
Precondition(p,s)-8s1.
(PlanExecution(s1) 4P-
SAT(s1,p))-((d � SAT(s,d)
4Precedes(s,s1))
Postcondition(p,s)-Plan(x)
4Situation(s)
A postcondition for a plan p can
be defined as a relation between
a situation s and a plan p,
implying that after plan
executions of that plan to occur, a
situation should satisfy some
description
Postcondition(p,s)-8s1.
(PlanExecution(s1) 4P-
SAT(s1,p))-((d � SAT(s,d)
4Precedes(s1,s))
2. Description of a business process domain
Mechatronic engineering is one of the most recentbranches of engineering, which has increasing impact onmany sectors of the economy and on the society overall[5]. The mechatronic engineering processes cover aninterdisciplinary combination of different domains com-prising of mechanical engineering, electrical engineering,and software engineering. Each domain covers a specificmechatronic field, while the intersection of knowledgemodels between these different engineering domains isconnected through the mechatronic processes. The abilityto integrate various mechatronic knowledge models andto articulate business processes based on them are centralkey to effectively manipulating knowledge resources.Hence, the DOLCE foundational ontology has been chosenas the working hypothesis from which the modellingof the mechatronic domain and process ontologiesstarted [5].
The DOLCE ontology aims at capturing the maincognitive categories, such as endurants and perdurants,underlying existing ontologies and human commonsensethat appears even in the domain of mechatronics.The main difference between endurants and perdurants isrelated to their behaviour in time, e.g. endurants canchange in time, while perdurants cannot. Furthermore, theDDPO module specialises the concepts and relationsdefined in DOLCE, and extends Descriptions and Situations(D&S) module that involves a representation language forthe tasks and processes [6]. In this paper, the ability totransform the DDPO theoretical model into the BPELbusiness processes is represented as an essential tasktowards semantically meaningful business process execu-tion via the BPEL workflow engine. As BPEL is notequipped with the formal semantics, exchanging theinformation between semantics and non-semantics datamodels needs a mechanism that is able to couple semanticexpressions of the DDPO process models with thebusiness process models. Therefore, we have involvedthe Pi-Calculus process algebra to provide accuratetransformations between the different levels of semanticexpressiveness of ontological models (expressed in OWLand based on the DDPO) and business process models(expressed in BPEL). In this way, different levels ofsemantic expressiveness enable the original semanticdefinitions to take a part of the business processesimplementation, and to reduce the possible mistakes insemantic interpretation of the different domains.
Here, we represent a business process trinity mechan-ism that translates semantic expressions of the DDPOtheoretical models into the Pi-Calculus and additionallyprovides the underlying semantics for the BPEL executableprocesses.
3. Business process trinity: DDPO, Pi-Calculus, BPEL
In this section, a brief description of the followingthree elements of the business process trinity mechanismis given: (a) the syntax and semantics of the DDPOtheoretical model, (b) the Pi-Calculus syntax and opera-tional semantics, and (c) the syntax and semantics of theBPEL executable processes.
3.1. DDPO
The purpose of the DDPO is to specify DOLCE plans atthe abstract level by using First Order Logic (FOL).
ARTICLE IN PRESS
V. Damjanovic / Information Systems 35 (2010) 496–504498
Additionally, we employ the DDPO to provide automaticand semantically meaningful usage of knowledge thatdescribes tasks, description, and situation in which theprocesses can be applied [7]. We suggest reading [6] toprovide deeper insight into the DDPO formal character-ization.
The syntax and the semantics of the selectedconcepts and relations of the DDPO theoreticalmodel are represented in Table 1, whereas the syntaxof the selected DDPO tasks is explained separatelyin Table 2.
The purpose of the DDPO tasks is to describethe type of actions, theirs sequencing and the controlsperformed on them [6]. The DDPO tasks can becomplex and ordered, and their behaviour servesas the main point used to describe the businessprocesses and to align the knowledge models to the DDPOconcepts.
Table 2The syntax of the DDPO tasks (according to [6]).
Syntax of DDPO tasks Sem
Task(x) ¼ df Course(x) 4 y,z. Plan(y) 4 Defines(y,x) 4((IntentionalAgentiveRole(z) 3IntentionalFigure(z)) 4 Uses(y,z) 4DesireTowards(z,x)
A t
int
att
ComplexTask(x) ¼ df Task(x) 4 y,z. Task(y) 4 Task(z) 4 yaz 4Component(x,y) 4 Component(x,z)
A c
z) a
SequentialTask(x) ¼ df Complex Task(x) 4 (y,z. (Component(x,y) 4Component(x,z) 4yaz) 4 (Successor(y,z) 3 Successor(z,y))) 4 (:w.
Component(x,w) 4 ControlTask(w))
A s
rela
any
HybridTask(x) ¼ df ComplexTask(x) 4 y,z. Component(x,y) 4Component(x,z) 4 yaz 4 ControlTask(y) 4 ActionTask(z)
A h
tas
ElementaryTask(x) ¼ df :y. Component(x,y) 4 Task(y) An
ActionTask(x) ¼ df :y. Sequences(x,y) 4 PlanningActivity(y) An
pla
ControlTask(x) ¼ df Task(x) 4 (y. Sequences(x,y)-PlanningActivity(y)) 4z. Task(z) 4 DirectSuccessor(x,z)
A c
act
LoopTask(x) ¼ df ControlTask(x) 4 y,z,w,P. Task(y) 4 Action(z) 4Action(w) 4 zaw 4 DirectSuccessor(x,y) 4 Sequences(y,z) 4Sequences(y,w) 4MinimalCommonType(z,w,P)
A l
tas
min
CyclicalTask(x) ¼ df ComplexTask(x) 4 y,z,w. LoopTask(y) 4DirectSuccessor(y,x) 4 CaseTask(z) 4 DirectSuccessor(z,y)
4Component(x,z) 4 DeliberationTask(w) 4 DirectSuccessor(z,w)
4Component(x,w) 4ExitCondition(y,w)
A c
tas
exi
the
delExitCondition(x,y)-LoopTask(x) 4 DeliberationTask(y)
BranchingTask(x) ¼ df ControlTask(x) 4 y,z. Task(y) 4 Task(z) 4 yaz 4DirectSuccessor(x,y) 4 DirectSuccessor(x,z)
A b
tas
AlternateTask(x) ¼ df CaseTask(x) 4 y,z. DeliberationTask(y) 4DeliberationTask(z) 4 yaz 4 DirectSuccessor(x,y) 4 DirectSuccessor(x,z)
4:w. way 4 waz 4 DeliberationTask(w) 4DirectSuccessor(x,w)
An
del
ConcurrencyTask(x) ¼ df BranchingTask(x) 4 y,z. Task(y) 4 Task(z) 4 yaz
4DirectSuccessor(x,y) 4 DirectSuccessor(x,z) 4 e1,e2. (Perdurant(e1) 4Perdurant(e2) 4e1ae2 4 Sequences(y,e1) 4Sequences(z,e2)) -
Overlaps(e1,e2)
A c
exe
per
one
exeConcurrencyTask(x) - y. SynchroTask(y)
ParallelTask(x) ¼ df ConcurrencyTask(x) 4 y,z. Task(y) 4 Task(z) 4 yaz 4DirectSuccessor(x,y) 4 DirectSuccessor(x,z) 4e1,e2. (Perdurant(e1) 4Perdurant(e2) 4 e1ae2 4 Sequences(y,e1) 4 Sequences(z,e2))-
Coincides(e1,e2)
A p
tas
BeginningTask(x) ¼ df ControlTask(x) 4 y,p. (Task(y) 4 Plan(p) 4Component(p,x) 4 Component(p,y) 4 xay)-Successor(x,y)
A b
tas
EndingTask(x) ¼ df ControlTask(x) 4 p:y. (Task(y) 4 Plan(y) 4Component(p,x) 4 Component(p,y) 4 xay)-Successor(y,x)
An
defi
MaximalTask(x) ¼ df ComplexTask(x) 4 y. (Task(y) 4 Component(p,y)) -
Part(x,y)
A m
in a
3.2. Pi-Calculus
The Pi-Calculus process algebra represents the form ofmathematical formalisms for describing and analyzing theproperties of concurrent computation [8]. It is distin-guished from the other process algebras (e.g. Calculus forCommunicating Systems (CCS), Communicating Sequen-tial Processes (CSP), and Algebra of CommunicatingProcesses (ACP)) in terms of mobility. Mobility is acharacteristic of all the processes that refers to the wayin which processes evolve as they execute [8].
Each process consists of one or more actions, whichcan be arranged sequentially, in parallel or conditionalpaths, or recursively [9]. An action is the sending orreceiving of information on a channel. According to thePi-Calculus convention, when one process sends informa-tion to another, it includes the name of the channel to beused in response to changing conditions. The channels can
antics
ask x is defined (df) as a course x in which a plan y has at least one
entional agentive role z or one intentional figure z and uses a desire
itude towards task x
omplex task x is defined as a task that has at least two other tasks (y and
s components
equential task x is defined as a complex task that includes a successor
tion among any two component tasks (y and z) and does not contain
control task w
ybrid task x is defined as a complex task that has at least one control
k y and one action task z as a component
elementary task x is defined by an atomic task y
action task x is defined as an elementary task that sequences non-
nning activities y
ontrol task x is defined as an elementary task that sequences a planning
ivity y. It has at least one direct successor task z
oop task x is defined as a control task that has as successor y an action
k that sequences at least two distinct activities (z and w) sharing a
imal common set of properties
yclical task x is defined as a complex task that is controlled by a loop
k y and has a case task z as a component. The case task z specifies the
t condition(s) of the cyclical task indirectly w, while a loop task specifies
exit condition. The exit condition can be used to state what
iberation task y causes to exit the cycle
ranching task x is defined as a control task that articulates a complex
k into an ordered set of tasks
alternate task x is defined as a case task branching to exactly two
iberation tasks (z and w)
oncurrency task x is defined as a task branched to a set of tasks
cutable concurrently, which means that no deliberation task is
formed in order to choose among them. A concurrency task has at least
successor synchronization task, which is aimed at waiting for the
cution of all tasks direct successor to the concurrent one
arallel task x is defined as a concurrent task branching to at least two
ks (y and z) that sequence temporally coinciding perdurants (e1 and e2)
eginning task x is defined as a control task that is the predecessor of all
ks defined in the plan p
ending task x is defined as a control task that has no successor tasks
ned in the plan y
aximal task x is defined as a complex task that has all the tasks defined
plan as components y
ARTICLE IN PRESS
V. Damjanovic / Information Systems 35 (2010) 496–504 499
act both as transmission medium and as transmitted data[10]. The communication is done on complementarychannels (input and output). The contents of messagesare also channels.
The core syntax of the Pi-Calculus processes, accordingto [8], is shown in Table 3.
In the Pi-Calculus, processes are written using theformal model shown in Fig. 1 [9]: The process definitionpart of the Pi-Calculus formal model explains that everyidentifier A is associated with a process definition of theform A(x1,y,xk) ¼ P. Summation offers a choice of thesummands expressing sequential behaviour of the processP. Parallel composition allows all components to proceedexpressing concurrent behaviour of the process P. Finally,process expression defines a local channel name x to beused within the process P implementing process encap-sulation.
A system described using the Pi-Calculus can evolve indifferent ways depending on the interactions amongprocesses. The laws which govern the static relationsbetween processes are known as the static structural
congruence, while the laws that rule their interactionrepresent the reduction relations (the operational seman-tics) [8]. The semantics of the Pi-Calculus consists of boththe structural congruence and the reduction relations.
Today, there are three major areas that aredirectly impacted by using the Pi-Calculus such as thefollowing [8]:
�
TabThe
P::
0
jxðu
jxhu
|(x)
|P1|
jP
i
|if (
|if (
j! � x
Pi-Calculus is implemented in the Erlang language,which is the primary language for programmingtelephone networks;
� Pi-Calculus is implemented in LOTOS, which hasbecome an ISO standard used widely by NASA for thevery complex and delicate temporal reasoning pro-blems in their space missions; and
le 3core syntax of the Pi-Calculus process P.
¼
(nil)
Þ (input: receiving u along channel x)
i (output: sending u along channel x)
P (restriction : referring to encapsulation)
P2 (parallel composition : referring to concurrency)
xiðuÞ � Pi (alternative composition: referring to sum; sequence)
x ¼ y) then P1 (conditional: referring to match)
xay) then P2 (conditional: referring to mismatch)
ðuÞ � P (replication)
Fig. 1. The Pi-Calculus
�
Pi-Calculus provides the theoretical underpinnings formost of the major Business Process Modelling (BPM)standards. That represents approach to formal seman-tics that makes the description of all constructs of abusiness model and offers a good basis for validationand reasoning about the business processes.3.3. BPEL
BPEL enables realization of Service Oriented Architec-ture (SOA) through composition, coordination, andorchestration of Web services [11]. It represents a work-flow-based language that describes sophisticated businessprocesses that orchestrate Web services. As an orchestra-tion language, it supports activities for communicatingwith other Web services, as well as handling workflowsemantics. The core syntax of the BPEL processes [11] isshown in Table 4.
BPEL syntax is defined by a BPEL XML Schema (XMLS),which describes the following kind of BPEL activities:
(a)
form
TablThe
B:: ¼
emp
|invo
|invo
|rece
|repl
|thro
|com
|sequ
|flow
|pick
|swit
|scop
Basic activities: throw, assign, wait, empty, compen-sate, terminate;
(b)
Partner activities: receive, reply, invoke; and (c) Structured activities: sequence, switch, while, pick, andflow.
BPEL uses all of these constructs for describing thebehaviour of the business processes (Web services).Additionally, they are described using Web ServiceDefinition Language (WSDL) interface definitions thatdefine available functions and the mechanism by whichBPEL processes can be accessed, e.g. Web services are
al model.
e 4core syntax of the BPEL process B.
ty (empty)
ke(x, i, o) (synchronous invocation (request-reply))
ke(x, i) (asynchronous invocation (one-way))
ive(x, i) (receive)
y(x, o) (reply)
w(f, o) (throw)
pensate(z, o ) (compensate)
ence(A, A0) (sequence)
(A, A0) (parallel)
((x, i1, A), (x, i2, A)) (alternative)
ch(x ¼ x0) A; A0 (conditional)
ez(A, Se, Sf, A0) (scope)
ARTICLE IN PRESS
V. Damjanovic / Information Systems 35 (2010) 496–504500
defined using the following elements [12]:
(a)
types, which provides datatype definitions used todescribe the messages exchanged;(b)
message, which represents an abstract definition ofthe data being transmitted;(c)
portType, which is a set of abstract operations. Eachoperation refers to an input message and outputmessages;(d)
binding, which specifies concrete protocol and dataformat specifications for the operations and messagesdefined by a particular portType;(e)
port, which specifies an address for a binding, thusdefining a single communication endpoint; and(f)
service, which is used to aggregate a set of related ports.Implementing a BPEL process by describing it in the BPELfile is not enough to make this business process executable.Certain rules and mapping formalisms between semanticallydescribed knowledge, on the one hand, and BPEL and WSDLdefinitions, on the other hand, must be defined in order toenable semantically meaningful execution of the businessprocesses. However, as both BPEL and WSDL cannot expresssemantic description of business processes, neither providewell-defined semantics for automated composition andexecution of business process [11], we continue lookingfurther into the appropriate formalisms able to semanticallyarticulate execution of the business processes.
4. Semantic business process transformation scenario
The BPEL defines two kinds of processes [13]:
(a)
executable processes that can be executed by the BPELworkflow engine; and(b)
abstract processes (business protocols) that explainmessage exchange patterns.Fig. 2. The semantic business proc
The BPEL executable processes describe the controlflow for orchestrating data sources (e.g. *.bpel file) and the
interfaces to external data sources (e.g. *.wsdl file),whereas BPEL abstract processes are not executable andcould be used just to guide executable processes.In order to implement the business process trinitymechanism that translates semantic expressions of theDDPO models (expressed as an *.owl file) into thePi-Calculus that additionally gives the semantics for BPELexecutable business processes (*.bpel and *.wsdl file), weapply a rule-based approach to Web service orchestrationand choreography. The proposed solution is based onModel-Driven Architecture (MDA) [14] that enablesdefining models at various levels of abstraction anddeveloping appropriate transformations between thesemodels. The transformation models conform to both thetransformation metamodels that define the model trans-formation semantics and the meta-metamodel [15]. Themetamodels are specified using Meta-Object Facility(MOF), which is a modelling language for expressing arange of information models and modelling systems [16].The MOF metadata architecture is used as a four layerframework, which includes the following layers shown inFig. 2:
�
ess
the MOF data layer (M0) that refers to the informationthat we wish to describe;
� the MOF model layer (M1) that contains the definitionof the required structures;
� the MOF metamodel layer (M2) that defines the termsin which the model is expressed; and
� the MOF meta-metamodel layer (M3) that defines theterms used to specify metamodels. It is the languagefor defining different kinds of metadata.
Each model from the M1 layer conforms to anappropriate metamodel from the M2 layer. At the same
transformation scenario.
ARTICLE IN PRESS
V. Damjanovic / Information Systems 35 (2010) 496–504 501
time, all MOF layers can belong to the different TechnicalSpaces (TSs) that according to Object Management Group(OMG) definition represent ‘‘a working context with a setof associated concepts, body of knowledge, tools, requiredskills, and possibilities.’’ As it is shown in Fig. 2, the M2and M3 layers belong to the MOF TS, whereas the M1 layerinvolves the Semantic Web TS, MOF TS and XML TS.The exchanging model between different TSs requiresthe transformation models to be defined. At the sametime, performing model transformation cannot always bedone in just one step. For example, in the Semantic WebTS (Fig. 2), the knowledge about mechatronic businessprocesses is expressed through the DDPO model and usesOWL RDF/XML presentation syntax (an *.owl file). In orderto enable communication between the Semantic Web TSand MOF TS, we transform *.owl file into an equivalent*.ecore (ECore) file, which is expressed using OWL RDF/XMI exchange syntax XML Metadata Interchange (XMI)that is an interchange format used for serialization ofmodels of other languages (metamodels). In the next step,we use the Atlas Transformation Language (ATL) engine[15] for specifying and implementing the relevant trans-formation rules between OWL RDF/XMI and Pi-Calculus/XMI metamodel definitions. The resulting Pi-Calculus/XMIconstructs are further transformed into both BPEL/XMIand WSDL/XMI metamodel definitions for which wedefine the following two transformation models: thePI2BPEL and the PI2WSDL. As the main results ofperforming the proposed transformation models, weobtain the BPEL and the WSDL files represented in XMIinterchange format. Finally, we transform the resultingBPEL/XMI and WSDL/XMI files into appropriate BPEL andWSDL files that belong to the XML TS and are executablevia the BPEL workflow engine.
For the sake of simplifying the transformationmodel (Fig. 2), we represent all three TSs (Semantic
Fig. 3. The ‘‘Semantic-Rule-Action’’ sens
Fig. 4. Mapping from the OWL DDPO-based Ele
Web, MOF and XML TS) by using the following notions(see Fig. 3):
(a)
e of
ment
a semantic sense;
(b) a rule (causal) sense; and (c) an action sense of the semantic business processtransformation scenario.
The semantic sense of the transformation scenarioinvolves the DDPO-based OWL RDF/XML file in whichthe ontology-based knowledge about mechatronic busi-ness processes is defined. The rule (causal) sense of thetransformation scenario consists of the transformationmodels that are applied to OWL RDF/XMI file andtransformed into the BPEL and WSDL exchange syntax.Finally, the action sense of the scenario transforms theBPEL and WSDL exchange syntax into the BPEL and WSDLpresentation syntax that gives ability to (semi-)automaticexecution of the semantic business processes.
A collection of transformation rules have been appliedto enable mapping from the OWL–DL metamodel into theBPEL and WSDL metamodel classes. An example ofmapping from the OWL Class, which is interpreted bythe DDPO Elementary task, into the Pi-Calculus Operator
metamodel class, and then, into the BPEL Throw and WSDLmetamodel classes, is shown in Fig. 4. For each task fromthe DDPO theoretical model we have found an appropriateactivity from the category of the BPEL activities, the BPELPartner activities, and the BPEL Structured activities.Comparing the syntax requirements of the DDPO tasksand BPEL activities, we define the transformation rules.For example, mapping from the OWL Class, that isadditionally aligned to the DDPO theoretical model (DDPO
Elementary task), into the Pi-Calculus Operator metamodelclass requires various constructs of the DDPO theoretical
the transformation scenario.
ary task into the BPEL Throw activity.
ARTICLE IN PRESS
V. Damjanovic / Information Systems 35 (2010) 496–504502
model to be considered. An example of such mapping isexplained in more detail in the following section. For adetailed example of a mechatronic use case in which wehave applied the proposed semantic business processtransformation scenario, we refer the reader to [17].
4.1. An example of mapping the DDPO Elementary task into
the Pi-Calculus Operator class
Semantically meaningful execution of the businessprocesses requires structured collaboration, orchestration,and choreography of particular business processes, theirsactivities and tasks. In this section, we describe a way ofestablishing the semantic relations between the DDPOOWL-based constructs and the BPEL processes throughthe Pi-Calculus metamodel. As an example, we show thesyntax of the DDPO ElementaryTask that is represented inTable 5.
The following are the steps that enable transformationof the DPPO Elementary task into the Pi-Calculus Operator
class [7]. First, we transform the syntax of the DDPOElementaryTask into the graphical representation thatinvolve appropriate workflow pattern (e.g. parallel split),which is shown in Fig. 5. Then, we define the Pi-Calculusbased semantics of the DDPO ElementaryTask, which isrepresented by the definitions (1)–(3). The DDPO Elemen-
tary task (that is defined by map relation in (3)) is anatomic task (defined by atom relation in (2)), with nocomponents (defined by no_com relation in (1)).
Componentðx; yÞ �!no_com
comðx; yÞno_com � tComponentðx;yÞ � Componentðx; yÞ0
(1)
Table 5Syntax of the DDPO Elementary task (according to [6]).
DDPO tasks Semantics
ElementaryTask(x) ¼ df :y.
Component(x,y) 4 Task(y)
An elementary task x is defined as
an atomic task y
Component(x,y) ¼ df
ProperPart(x,y) 4d,z,w.
Description(d) 4Role(z) 4Role(w)
4Uses(d,z) 4Uses(d,w)
4Selects(z,x) 4Selects(w,y)
A component relation is defined as a
proper part relation qualified by a
description d in which the proper
parts (z and w) are involved
Task(x) ¼ df Course(x) 4 y,z.
Plan(y) 4 Defines(y,x) 4((IntentionalAgentiveRole(z)
3IntentionalFigure(z)) 4 Uses(y,z)
4 DesireTowards(z,x)
A task x is defined (df) as a course x
in which a plan y has at least one
intentional agentive role z or one
intentional figure z and uses a desire
attitude towards task x
Fig. 5. A graphical representation of the DDPO Elementary task.
TaskðyÞ�!atom
elðyÞ � tTaskðyÞ � TaskðyÞ0 (2)
elementary TaskðxÞ�!map
t�elementary TaskðxÞ � ðcomðx; yÞ � 0jelðyÞ � 0Þ
(3)
In the next step, the syntax of the DDPO Component
relation is given in the form of a graphical representationthat involves both the sequence and the parallel splitworkflow patterns (shown in Fig. 6) [7]. Starting fromFig. 6, the Pi-Calculus based semantics of the DDPOComponent is defined and represented by the definitions(4)–(8). The DDPO Component relation (that is defined bymap relation in (8)) is described as a proper part (definedby pp relation in (4)), which is further qualified bydescription (defined by dsc relation in (5)) in which theproper part z (defined by z relation in (6)) and the properpart w (defined by w relation in (7)) are involved.
proper Partðx; yÞ�!pp
tproper Partðx;yÞ � ðppðx; yÞ � 0jppðy; xÞ � 0Þ
(4)
DescriptionðdÞ�!dsc tdescription � d1 � 0 (5)
RoleðzÞ�!z trole � z1 � 0 (6)
RoleðwÞ�!w trole �w1 � 0 (7)
Componentðx; yÞ�!map
tproperPartðx;yÞ � ppðx; yÞ
� 0jd1 � tcomponentðx;yÞ � Componentðx; yÞ0
jz1 � tcomponentðx;yÞ � Componentðx; yÞ0jw1
� tcomponentðx;yÞ � Componentðx; yÞ0 (8)
Finally, the syntax of the DDPO Task is given in the formof a graphical representation that involves both thesequence and the multi merge workflow patterns (shownin Fig. 7). Based on Fig. 7, the semantics of the DDPO Task
is described by the definitions (9)–(14). The DDPO Task
(that is defined by map relation in (9)) is a course (that isfurther defined by cur relation in (10)) in which a plan
Fig. 6. A graphical representation of the DDPO Component.
ARTICLE IN PRESS
V. Damjanovic / Information Systems 35 (2010) 496–504 503
(defined by pl relation in (11)) has at least one intentionalagentive role z (defined by ag_role relation in (12)) or oneintentional figure z (defined by fig. relation in (13)) anduses a desire attitude z, which describes the intentionalagentive role and/or the intentional figure towards task x
(defined by map relation in (14)).
TaskðxÞ�!tsk ttask � c � 0 (9)
CourseðxÞ�!cur
c � tcourse � CourseðxÞ0 (10)
Fig. 7. A graphical representa
Table 6The metamodel-based transformation rules.
DDPO OWL
metamodel
class
Pi-Calculus
metamodel class
BPEL
metamodel
Explanation of
Plan OWL
ontology
Pi-Calculus process BPEL process DDPO Plan is a
and has at leas
used for repres
Process represe
process that is
Goal OWL
statement
Pi-Calculus agent-
activity
BPEL
partnerlink
Each DDPO Plan
descriptions as
could be furthe
Activity describ
define different
Elementary
task
OWL class Pi-Calculus operator BPEL throw;
BPEL empty.
DDPO Elementa
the same time,
describe the ag
process needs t
of a ‘‘no-op’’ in
concurrent acti
Branching
task
OWL class Pi-Calculus operator BPEL sequence DDPO Branching
of tasks. The BP
sequentially, in
Parallel task Intersection Pi-Calculus parallel
composition
BPEL pick DDPO Parallel t
temporally coin
of the processe
execution. It is
occurrence of o
event that occu
activity to perf
Alternate
task
OWL
unionof
Pi-Calculus
alternative
composition
BPEL pick DDPO Alternate
UnionOf statem
class extension
extensions of t
Hybrid task OWL class Pi-Calculus operator BPEL receive,
BPEL reply
DDPO Hybrid ta
as a componen
wait for a matc
process to send
The combinatio
the WSDL port
Ending task OWL class Pi-Calculus operator BPEL
terminate
DDPO Ending ta
the BPEL Termin
business proce
PlanðyÞ�!map
tplan � p � 0 (11)
IntentAgent RoleðzÞ �!ag_role
tIntentAgent Role � i � 0 (12)
Intent FigureðzÞ�!fig
tIntent Figure � i � 0 (13)
PlanðyÞ�!map
!i � tplan � PlanðyÞ0 ¼ !i � usesðy; zÞ � PlanðyÞ0j!i
� desire Towardsðx; zÞ � PlanðyÞ0 (14)
tion of the DDPO Task.
transformation
description that uses at least one task, at least one agentive role or figure,
t one goal as a proper part [6]. Pi-Calculus Process is a central class that is
enting the interaction and communication among processes, while BPEL
nts a central class that is used for explaining the nature of the BPEL
implicitly connected with the DDPO Plan description.
has a goal as a proper part, and can also have regulations and other
proper parts. We transform the DDPO Goal to OWL Statement in a way that
r expressed by Pi-Calculus Agent Activity class. The Pi-Calculus Agent
es the resource allocation strategy, while the BPEL PartnerLink is used to
relationships to partners.
ry task represents an atomic task that is transformed into OWL Class. At
Pi-Calculus Operator class consists of a set of operators that are used to
ents and processes. BPEL Throw activity can be used when a business
o signal an internal fault explicitly. BPEL Empty construct allows insertion
struction into a business process that is useful e.g. for synchronization of
vities.
task is a control task that articulates a complex task into an ordered set
EL Sequence activity contains one or more activities that are performed
the order in which they are listed within the BPEL /sequenceS element.
ask is a concurrent task branching to at least two tasks that sequence
ciding perdurants [6]. OWL Intersection class links a parallel composition
s with the rest of the processes that participate in business process
analogous to logical conjunction. The BPEL Pick activity awaits the
ne of a set of events and then performs the activity associated with the
rred. If more than one of the events occurs, then the selection of the
orm depends on which event occurred first.
task is a case task branching to exactly two deliberation tasks. OWL
ent is analogous to logical disjunction. It describes a class for which the
contains those individuals that occur in at least one of the class
he class descriptions in the list.
sk is a complex task that has at least one control task and one action task
t. The /receiveS construct allows the business process to do a blocking
hing message to arrive. The /replyS construct allows the business
a message in reply to a message that was received through /receiveS.
n of a /receiveS and a /replyS forms a request-response operation on
Type for the process.
sk is a control task that has no successor tasks defined in the plan, while
ate activity can be used to immediately terminate the behaviour of a
ss instance within which the terminate activity is performed.
ARTICLE IN PRESS
Table 7OWL metamodel classes currently without interpretation in the Pi-
Calculus metamodel.
AllValuesFromRestriction, SomeValuesFromRestriction
CardinalityRestriction, MaxCardinalityRestriction,
MinCardinalityRestriction
OWLAnnotationProperty, OWLOntologyProperty, Property,
FunctionalProperty, OWLObjectProperty, InverseFunctionalProperty,
SymmetricProperty, TransitiveProperty
V. Damjanovic / Information Systems 35 (2010) 496–504504
4.2. The semantic business process transformation rules
The following are the guiding transformation rules thatrelate between the DDPO constructs expressed inOWL–DL, the Pi-Calculus, and the BPEL metamodelelements. The metamodel based transformational rulesare explained in Table 6. There are a plenty of OWLmetamodel classes that currently do not have theirinterpretation in Pi-Calculus operational semantics, whichare shown in Table 7. For example, the impossibility toexpress the cardinality restrictions defined in OWL modelstrains to the problem of constraining the number ofvalues of a particular property, or the most importantproblem of expressing OWL properties that can lead to theloss of connections between e.g. instances of two classes,or instances of classes and RDF literals. Therefore, thefurther improvements of the semantic business processtrinity mechanism that is proposed in this paper shouldextend the existing set of the transformation rules tocover the rest of the OWL–DL metamodel constructs.We are particularly interested in extending Pi-Calculusmetamodel to cover OWL cardinality restrictions and bothOWL datatype and OWL object properties.
5. Conclusions
This paper discusses the use of the MDA and MOFapproaches as the mechanisms for semantic reengineer-ing of the ontological knowledge domains in order tosupport (semi-)automatic business process execution.Additionally, the paper represents the process knowledgeexpressed in the form of a Pi-Calculus process theory thatserves as a formalism to provide semantics between thedifferent levels of semantic expressiveness of ontologicaldata models and non-ontological business processmodels. Recently, the Pi-Calculus and its variants likeSpi-Calculus, Ambient calculus, etc., have found practicalapplications in a wide number of domains: from crypto-graphic protocols like ProVerif [18], Cryptyc,1 to thetheoretical basis of the BPML and XLANG [19], molecularbiology [20], LOTOS [21] and many more. A particularinterest of the Pi-Calculus is taken in getting a formalfoundation to the model and reasoning about the differentcollaboration techniques such as orchestration and chor-eography of the business processes. The interestingcases of using the Pi-Calculus are those that meetrequirements for the design of self-adaptive and self-
1 http://www.cryptyc.org/.
organizing systems that consider implementation ofprobabilistic algorithms to enable a random choice, aswell as asynchronous manifestation of processes thatoccur randomly in dynamic and distributed architectures.Therefore, we have found the Pi-Calculus process algebrato be the most convenient formalism to express the realnature of the business processes taking place in theSemantic Web environment. At the same time, we haveinvolved the DDPO theoretical model to provide semanti-cally meaningful usage of knowledge that describes thetasks, as well as the descriptions and situations in whichthe business processes can be applied.
References
[1] C. Masolo, S. Borgo, A. Gangemi, N. Guarino, Ontology Library,WonderWeb Del. D18, 2004.
[2] J. Nitzsche, D. Wutke, T. Van Lessen, An ontology for executablebusiness processes, in: M. Hepp, K. Hinkelmann, D. Karagiannis,R. Klein, N. Stojanovic (Eds.), Semantic Business Process and ProductLifecycle Management. Proceedings of the Workshop SBPM 2007,Innsbruck, CEUR Workshop Proceedings, ISSN 1613-0073, 2007.
[3] M. Hepp, D. Roman, An Ontology Framework for Semantic BusinessProcess Management, in: Proceedings of the Eighth InternationalConference Wirtschaftsinformatik, Germany, 2007.
[4] M. Fronk, J. Lemcke, Expressing Semantic Web Service Behaviorusing Description Logics, in: Proceedings of the ESWC 2006Workshop on SBPM 2006, Montenegro, 2006.
[5] V. Damjanovic, W. Behrendt, M. Ploßnig, M. Holzapfel, DevelopingOntologies for Collaborative Engineering in Mechatronics, in:Proceedings of the Fourth European Semantic Web Conference,ESWC 2007, Austria, 2007, pp. 190–204.
[6] A. Gangemi, S. Borgo, C. Catenacci, J. Lehmann, Task taxonomies forknowledge content, Metokis Deliverable (2004) D07.
[7] V. Damjanovic, DOLCE and Pi-Calculus Rendezvous Semantics forBusiness Processes, in: Proceedings of the First International Work-shop on Knowledge Reuse and Re-engineering over the SemanticWeb (KRRSW 2008), at ESWC 2008, Tenerife, Canary Islands, 2008.
[8] J. Parrow, An introduction to the Pi-Calculus, in: J.A. Bergstra,A. Ponse, S.A. Smolka (Eds.), Handbook of Process Algebra, Elsevier,Amsterdam, 2001, pp. 479–543.
[9] M. Havey, Essential Business Process Modelling: Best Practices forBuilding Process-Oriented Workflow Applications, O’Reilly, 2005.
[10] H. Smith, P. Fingar, Workflow is just a Pi Process, 2003. Online.Available at: /http://www.fairdene.com/picalculus/workflow-is-just-a-pi-process.pdfS.
[11] R. Lucchi, M. Mazzara, A Pi-Calculus based semantics for WS-BPEL,Journal of Logic and Algebraic Programming (JLAP) 70 (2006)96–118.
[12] Web Service Description Language (WSDL) 1.1, W3C Note, 2001.Online. Available at: /http://www.w3.org/TR/wsdlS.
[13] Business Process Execution Language for Web Services, ver. 1.1.2003. Online. Available at: /http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-bpel/ws-bpel.pdfS.
[14] J. Miller, J. Mukerji: MDA Guide Version 1.0.1, OMG Document,2003. Online. Available at: /www.omg.org/docs/omg/03-06-01.pdfS.
[15] ATLAS Group, ATL User Manual, 2006.[16] OMG MOF V13: Meta-Object Facility (MOF) Specification, March 2000.[17] V. Damjanovic, M. Plossnig, Bridging the gap between different
levels of business process modelling, in: Proceedings of theInternational Conference on Collaborative Mechatronic Engineer-ing, ICCME 2009, Salzburg, Austria, May 25–26, 2009.
[18] B. Blanchet, A. Chaudhuri, Automated Formal Analysis of a Protocolfor Secure File Sharing on Untrusted Storage, in: IEEE Symposiumon Security and Privacy, USA, 2008, pp. 417–431.
[19] BPEL4WS, A convergence path toward a standard BPM Stack,BPMI.org Position Paper, 2002.
[20] R. Aviv, W. Silverman, E.Y. Shapiro, Representation and simulationof biochemical processes using the pi-calculus process algebra,Pacific Symposium on Biocomputing 1 (2001) 459–470.
[21] E. Brinksma, International Standard ISO 8807:1989, Informationprocessing systems—Open Systems Interconnection-LOTOS—Aformal description technique based on the temporal ordering ofobservational behaviour.