Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases
-
Upload
marco-montali -
Category
Presentations & Public Speaking
-
view
97 -
download
1
Transcript of Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases
![Page 1: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/1.jpg)
On The Marriage of Colored Petri Nets and Relational Databases
Marco Montali Free University of Bozen-Bolzano
SOAMED 2016
DB-Nets
![Page 2: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/2.jpg)
Marrying processes and datais extremely difficult….
… but is a must if we want to really understand
how complex dynamic systems operate.2
![Page 3: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/3.jpg)
Our Research
3
Theory
Practice
![Page 4: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/4.jpg)
Our Research
4
Theory
Practice
![Page 5: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/5.jpg)
Our Approach
5
Business Process Management
Data Management
Conceptual Modeling
Formal Methods
Artificial Intelligence
![Page 6: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/6.jpg)
Dynamic Systems of Interest
• Business processes
• Multiagent systems
• Distributed systems
6
![Page 7: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/7.jpg)
Business Process Lifecycle
7
picture by Wil van der Aalst
![Page 8: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/8.jpg)
Formal Verification
Automated analysis of a formal model of the system
against a property of interest, considering all possible system behaviors
8
picture by Wil van der Aalst
![Page 9: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/9.jpg)
Two Questions
How to formally and conceptually account for the process+data interplay
in conventional, activity-centric BP models?
How to verify such BPMs?
9
![Page 10: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/10.jpg)
Two Questions
• How to formally and conceptually account for the process+data interplay in conventional, activity-centric BP models?
• How to verify such BPMs?
10
Business Turing Machines
BTMs
![Page 11: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/11.jpg)
11
![Page 12: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/12.jpg)
Data and Processes
12
ReviewRequest
Fill Reim-bursement
Review Reim-bursement
Rejected
Accepted
decision-making action
footprint
![Page 13: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/13.jpg)
Is this Synergy Reflected by Models?
Survey by Forrester [Karel et al, 2009]: lack of interaction between data and process experts.• BPM professionals: data are subsidiary to processes • Master data managers: data are the main driver for the
company’s existence • 83/100 companies: no interaction at all between these
two groups • This isolation propagates to models, languages and tools
13
![Page 14: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/14.jpg)
Conventional Data ModelingFocus: revelant entities, relations, static constraints
Supplier ManufacturingProcurement/Supplier
Sales
Customer PO Line Item
Work OrderMaterial PO
*
*
spawns0..1
Material
But… how do data evolve? Where can we find the “state” of a purchase order?
14
![Page 15: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/15.jpg)
Conventional Process ModelingFocus: control-flow of activities in response to events
But… how do activities update data? What is the impact of canceling an order?
15
![Page 16: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/16.jpg)
A Deployed Process
16
![Page 17: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/17.jpg)
Do you like Spaghetti?Manage
CancelationShipAssembleManage
Material POsDecompose
Customer PO
Activities
Process
Data
Activities
Process
Data
Activities
Process
Data
Activities
Process
Data
Activities
Process
Data
Customers Suppliers&CataloguesCustomer POs Work Orders Material POs
IT integration: difficult to manage, understand, evolve17
![Page 18: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/18.jpg)
Too Late!• Where are the data?
• Where shall we model relevant business rules?
18
Too late to reconstruct the missing pieces
Where is our data?part is in the DBs,part is hidden in the process execution engine.
Where are the relevant business rules, and how are they modeled?At the DB level? Which DB? How to import the process data?(Also) in the business model? How to import data from the DBs?
DataProcess
Supplier ManufacturingProcurement/Supplier
Sales
Customer PO Line Item
Work OrderMaterial PO
*
*
spawns0..1
Determine cancelation
penaltyNotify penalty
Material
Process Engine
Process State
Business rulesFor each work order W For each material PO M in W if M has been shipped add returnCost(M) to penalty
Diego Calvanese (FUB) Foundations of Data-Aware Process Analysis INRIA Saclay Paris – 18/3/2016 (10/1)
![Page 19: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/19.jpg)
19
![Page 20: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/20.jpg)
…There is Hope!20
data-centric…
…
…
activity-centric1998
…2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
N.B.: these are “sparse” dots!!!
![Page 21: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/21.jpg)
data-centric…
…
…
activity-centric1998
…2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
21
[PODS98, Abiteboul et al.]
Relational Transducers
[ICDT09, Vianu] Verification of artifact-centric
processes
[ICDT05, Vardi] Model checking
for database theoreticians
[ECAI12, _] Knowledge and action
bases
[PODS13, _] Data-Centric
Dynamic Systems
[STTT16, _] Case-centric
DCDS
[PODS13, _] Verification of data-centric processes
![Page 22: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/22.jpg)
data-centric…
…
…
activity-centric1998
…2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
22
[IBM J.,Nigam and Caswell] Business Artifacts
[OTM08, Hull] Survey on
business artifacts
[WSFM10, Hull et al.] First paper on IBM
GSM
First draft of OMG CMMN
Start of the EU Project
ACSI
![Page 23: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/23.jpg)
data-centric…
…
…
activity-centric1998
…2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
•[BPM2010, Richardson] BPM vs master data dichotomy•Data+Process integration key to:- assess value of processes and evaluate KPIs [Meyer et al, 2011]- aggregate relevant info, elicit business rules [ABDIS11, Dumas]
•[Reichert, 2012]: “Process and data are just two sides of the same coin”
[BPM09WS, Kūnzle and Reichert] First paper on Philharmonic Flows •
23
![Page 24: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/24.jpg)
data-centric…
…
…
activity-centric1998
…2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
[ICATPN07, Lazic et al.]
Data nets
[CAiSE10, Sidorova et al.]
Conceptual nets
[TCS11, Rosa-Velardo and de Frutos-Escrig]
ν-PNs (nets managing names)
[FAOC16, _] Verification of
PNs with names
[PN16, Lasota] Survey on PNs
with data
[PN15, Triebel and Sürmeli]
Algebraic PNs
![Page 25: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/25.jpg)
data-centric…
…
…
activity-centric1998
…2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
DB-NetsCPNs +
databases
[AAAI17, _] RAW-SYS
Workflow nets + databases
![Page 26: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/26.jpg)
One Step Back…
How do contemporary
activity-centric BPMSs account for the
process-data interplay?
26
![Page 27: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/27.jpg)
Example: BizAgi (~)
27
ReviewRequest
Fill Reim-bursement
Review Reim-bursement
Rejected
Accepted
![Page 28: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/28.jpg)
Case and Persistent DataReviewRequest
Fill Reim-bursement
Review Reim-bursement
Rejected
Accepted
req info result reimbursement
personal info
28
![Page 29: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/29.jpg)
Persistent Data Engineering
persistent storage29
ReviewRequest
Fill Reim-bursement
Review Reim-bursement
Rejected
Accepted
req info result reimbursement
personal info
framework data model custom code
![Page 30: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/30.jpg)
Case Data Engineering
persistent storage30
ReviewRequest
Fill Reim-bursement
Review Reim-bursement
Rejected
Accepted
req info result reimbursement
personal info
framework data model custom code
user forms
external services
![Page 31: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/31.jpg)
Recipe
• Explicit control-flow
• Local, case data
• Global, persistent data
• Queries/updates on the persistent data
• External inputs
• Internal generation of fresh IDs31
DATA-AWARE ACTIVITY CENTRIC PROCESS
![Page 32: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/32.jpg)
Colored Petri Nets
• In ν-PNs: explicit construct to create globally fresh data values (ν variables)
• No persistent data!32
![Page 33: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/33.jpg)
Recipe
• Explicit control-flow
• Local, case data
• Global, persistent data
• Queries/updates on the persistent data
• External inputs
• Internal generation of fresh IDs33
COLORED PETRI NETS
Using ν variables
![Page 34: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/34.jpg)
Data layer: relational DB with constraints (monolithic data)
Process layer: evolves an instance of the DB• Condition-action rules: action executability, provide parameters • Atomic actions: conditional CRUD operations with external
inputs
Data-Centric Dynamic Systems
34
unibz.itunibz.it
IntroductionData-Centric Dynamic Systems (DCDSs)An abstract, pristine framework to formally describe processes that manipulatedata.
• Captures virtually all existing approaches to data-aware processes, such asthe artifact-centric paradigm.
DCDS
Data Layer
Process Layer
external
service
external
service
external
service
Update
Read
• Data layer: relational database (with constraints).• Process layer: condition-action rules (include service calls that input new
data).
Marco Montali Verification of Relational DCDSs PODS 2013 3 / 25
![Page 35: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/35.jpg)
Recipe
• Explicit control-flow
• Local, case data
• Global, persistent data
• Queries/updates on the persistent data
• External inputs
• Internal generation of fresh IDs35
DATA-CENTRIC DYNAMIC SYSTEMS
~Can be simulated
![Page 36: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/36.jpg)
Marriage
![Page 37: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/37.jpg)
DB-Nets
37
persistence layer
data logic layer
control layer
DB
ActionsQueries
View places Places Transitions
fetch update
populate trigger
ArcsRead arcsRollback arcs
Fig. 1. The conceptual components of db-nets
it employs workflow nets [1] for capturing the process control flow, without lever-aging the advanced capabilities of CPNs. Taking inspiration from [15], we thenpropose db-nets, a new, balanced formal model for data-aware processes, rootedin CPNs and relational databases. We rigorously describe the abstractions of-fered by the model, and formalize its execution semantics. We finally invite theresearch community to build on this new model, discussing its potential alongthree subjects: modeling, verification, and simulation.
2 The DB-Net Model
In our formal model, called db-net, we combine the distinctive features of CPNsand relational databases into a coherent framework, sketched in Figure 1. Themodel is structured in three layers:• persistence layer, capturing a full-fledged relational database with constraints,and used to store background data, and data that are persistent across cases.
• control layer, employing a variant of CPNs to capture the process control-flow,case data, and possibly the resources involved in the process execution.
• data logic layer, interconnecting in the persistence and the control layer.Thanks to the data logic, the control layer is supported in querying the un-derlying persistent data and tunes its own behavior depending on the obtainedanswers. Furthermore, the data logic may be exploited by the control layer to up-date the persistent data depending on the current state, the data locally carriedby tokens, and additional data obtained from the external world. We formalizethe framework layer by layer, from the bottom to the top.
2.1 Persistence Layer
The persistence layer maintains the relevant data in the domain of interest. Tothis end, we rely on standard relational databases equipped with constraints,in the spirit of [9]. First-order (FO) constraints allow for the formalization ofconventional database constraints, such as keys and functional dependencies, aswell as semantic constraints reflecting the domain of interest. Di↵erently from[9], though, we also consider data types, on the one hand resembling concretelogical schemas of relational databases (where table columns are typed), and onthe other reconciling the persistence layer with the notion of “color” in CPNs.
joint proposal with Andy Rivkin
![Page 38: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/38.jpg)
Persistence LayerTyped relational DB with constraints • DB: set of relation schemas with typed components • Type: data domain with rigidly defined predicates • Constraints: Domain-independent FO sentences
• Keys, FKs, dependencies, multiplicities, … DB Instance: finite set of typed facts over DB, satisfying all constraints
38
![Page 39: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/39.jpg)
Persistence LayerTyped relational DB with constraints • DB: set of relation schemas with typed components • Type: data domain with rigidly defined predicates • Constraints: Domain-independent FO sentences
• Keys, FKs, dependencies, multiplicities, … DB Instance: finite set of typed facts over DB, satisfying all constraints
39
That’s just the relational model!
![Page 40: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/40.jpg)
Example
40
Empname: string
Ticketid: int descr: string
Respemp: string ticket: int
Each employee can handle at most one ticket at a given time
Logticket: int emp: string descr: string
![Page 41: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/41.jpg)
Data LogicBidirectional interface for interacting with a DB instance of the persistence layer
41
Read-mode: query • open, domain-independent FO
formula • answers: substitutions of free
variables s.t. the resulting FO sentence is true in the DB instance
Write-mode: action • Name • Parameters • Add and delete list
• Templates of facts using parameters and constants…
• …to be added to/removed from the current DB instance
• Transactional semantics: commit vs roll-back
That’s just SQL!
![Page 42: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/42.jpg)
Example: Queries
• Get tickets and their description
• Get “idle” employees
42
To query the database instance, we use FO(D) queries as in Definition 5. Toupdate the database instance, we instead resort to the literature on data-centricprocesses [33, 11], where actions are typically used to apply CRUD (create-read-update-delete) operations over a relational database. Specifically, we adopt aminimalistic approach, keeping the actions as simple as possible. The approachis inspired by the well-known STRIPS language for planning, which has beenadopted also in for data-centric processes [5]. More sophisticated forms of actions,as those in [9], can be seamlessly introduced.
Definition 12 (Action). A (parameterized) action over a D-typed persistencelayer hR, Ei is tuple hn, ~p, F+
, F
�i, where: (i) n is the action name; (ii) ~p is atuple of pairwise distinct typed variables from VD, denoting the action (formal)parameters. (iii) F
+ and F
� respectively represent a finite set of R-facts over~p, to be added to and deleted from the current database instance. Given a typedrelation R(D1, . . . ,Dn
) 2 R, an R-fact over ~p has the form R(y1, . . . , yn), suchthat for every i 2 {1, . . . , n}, y
i
is either a value o 2 �Di , or a variable x 2 ~p
with type(x) = Di
. An R-fact is an R-fact for some relation R from R. ⇤
To access the di↵erent components of an action ↵ = hn, ~p, F+, F
�i, we use a dotnotation: ↵·name = n, ↵·params = ~p, ↵·add = F
+, and ↵·del = F
�.We now turn to the semantics of actions. Actions are executed by grounding
their parameters to values. Given an action ↵ and a (parameter) substitution✓ for ↵, we call action instance ↵✓ the (ground) action resulting from ↵ bysubstituting its parameters with corresponding values, as specified by ✓.
Definition 13 (Action instance application). Let P = hR, Ei be aD-typedpersistence layer, I be a D-typed database instance I compliant with D, ↵ be anaction over P, and ✓ be a substitution for action·params. The application of ↵✓ onI, written apply(↵✓, I), is a database instance overR obtained as (I\F�
↵✓
)[F+↵✓
,where: (i) F
�↵✓
=S
R(~y)2↵·delR(~y)✓; (ii) F
+↵✓
=S
R(~y)2↵·addR(~y)✓. We say that↵✓ can be successfully applied to I if apply(↵✓, I) complies with P. ⇤
The application of an action instance amounts to ground all the facts containedin the definition of the action as specified by the given substitution, then ap-plying the update on the given database instance, giving priority to additionsover deletions (this is a standard approach, which unambiguously handles thesituation in which the same fact is asserted to be added and deleted).
The data logic simply exposes a set of queries and a set of actions that canbe used by the control layer to obtain data from the persistence layer, and toinduce updates on the persistence layer.
Definition 14 (Data logic layer). Given a D-typed persistence layer P, a D-typed data logic layer over P is a pair hQ,Ai, where: (i) Q is a finite set of FO(D)queries over P; (ii) A is a finite set of actions over P. ⇤
Example 2. We make the scenario of Example 1 operational, introducing a data logiclayer L over P. L exposes two queries to inspect the persistence layer:• Qe(e):-Emp(e) ^ ¬9t.Resp(e, t), to extract idle employees;
• Qt(t, d):-Ticket(t, d), to extract tickets and their description.In addition, L provides three main functionalities to manipulate tickets in persistencelayer: ticket registration, assignment/release, and logging. Such functionalities are re-alized through four actions (where, for simplicity, we blur the distinction between anaction and its name). The registration of a new ticket is managed by an action reg
that, given an integer t, and two strings e and d, (reg·params = ht , e, di, simultane-ously creates a ticket identified by t and described by d into the persistence layer, andassigns the employee identified by e to such ticket (thus making her busy):
reg·del = {Emp(e, idle)} reg·add = {Ticket(t , d),Resp(e, t)}
Two specular actions assign and release are exposed to assign or release a ticketto/from an employee, making her busy or idle. Both actions take as input a string forthe employee name and an integer for a ticket it (assign·params = release·params =he, ti), and update e by removing or adding that e is responsible of t:
release·del = assign·add = {Resp(e, t)} release·add = assign·del = ;
Finally, an action log with log·params = ht , e, di is exposed to flush the informationrelated to a ticket into a log table. The action erases all information about the ticket,and logs that it has been processed, also recalling its employee and description:
log·del = {Ticket(t , d),Resp(e, t)} log·add = {Log(t , e, d)}
2.3 Control Layer
The control layer employs a variant of CPNs to capture the process control flow,and how it interacts with an underlying persistence layer through the function-alities provided by the idata logic. The spirit is to conceptually ground CPNsby adopting a data-oriented approach. This is done by introducing dedicatedconstructs exploiting such functionalities, as well as simple, declarative patternsto capture the typical token consumption/creation mechanism of CPNs.
Before introducing the di↵erent constitutive elements of the control layertogether with their graphical appearance, we fix some preliminary notions. Weconsider the standard notion of amultiset. Given a set A, the set of multisets overA, written A
�, is the set of mappings of the form m : A ! N. Given a multisetS 2 A
� and an element a 2 A, S(a) 2 N denotes the number of times a appearsin S. Given a 2 A and n 2 N, we write a
n 2 S if S(a) = n. We also consider theusual operations on multisets. Given S1, S2 2 A
�: (i) S1 ✓ S2 (resp., S1 ⇢ S2)if S1(a) S2(a) (resp., S1(a) < S2(a)) for each a 2 A; (ii) S1 + S2 = {an |a 2 A and n = S1(a) + S2(a)}; (iii) if S1 ✓ S2, S2 � S1 = {an | a 2 A and n =S2(a)� S1(a)}; (iv) given a number k 2 N, k · S1 = {akn | an 2 S1}.2
Places. The control layer contains a finite set P of places, which in turn areclassified in two groups. On the one hand, so-called control places play the roleof standard places in classical Petri nets: they represent conditions/states of adynamic system. On the other hand, so-called view places are used as an interface
2 Hence, given a multiset S, we have 0 · S = ;.
![Page 43: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/43.jpg)
• REGISTER(t,d,e): register ticket t with description d, assigning it to employee e• Add Ticket(t,d), Resp(e,t)
• ASSIGN(e,t): assign employee e to ticket t• Add Resp(e,t)
• RELEASE(e,t): release employee e from managing ticket t• Del Resp(e,t)
• LOG(t,e,d): flush and log the info related to ticket t• Del Ticket(t,d), Resp(e,t) • Add Log(t,e,d)
Example: Actions
43
![Page 44: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/44.jpg)
• REGISTER(t,d,e): register ticket t with description d, assigning it to employee e• Add Ticket(t,d), Resp(e,t)
• ASSIGN(e,t): assign employee e to ticket t• Add Resp(e,t)
• RELEASE(e,t): release employee e from managing ticket t• Del Resp(e,t)
• LOG(t,e,d): flush and log the info related to ticket t• Del Ticket(t,d), Resp(e,t) • Add Log(t,e,d)
Rolls back if e is already managing another
Example: Actions
44
Roll back if e is already managing another ticket
Rolls back if t already exists with a different description
![Page 45: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/45.jpg)
Control Layer
A “data-oriented” CPN
• Process control-flow
• Evolution of tokens and their “case” data
• Interaction with the persistence layer via the data logic layer
45
![Page 46: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/46.jpg)
PlaceColored condition/state of the control layer
• Color: ordered combination of types
• Tokens carry tuples of data over the corresponding types
• Two types of place, to distinguish local and global data
46
![Page 47: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/47.jpg)
Normal Place
• Represent case states and resources • Color: schema of the local data carried by tokens • May be seen as a special relation of the
persistence layer • Tokens explicitly manipulated by the control layer,
as customary in CPNs
47
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
![Page 48: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/48.jpg)
View Place• “View” of the persistence layer provided to the
control layer • Hosts the answers to a query from the data logic
• Color must be compatible with the returned answers • Clearly identifies where the control layer needs to
“read” from the persistence layer • Not modified explicitly by the control layer • Implicitly updated by applying actions on the
persistence layer, and recomputing the view
48
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
![Page 49: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/49.jpg)
Example
49
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
int int⇥ string int⇥ string
To query the database instance, we use FO(D) queries as in Definition 5. Toupdate the database instance, we instead resort to the literature on data-centricprocesses [33, 11], where actions are typically used to apply CRUD (create-read-update-delete) operations over a relational database. Specifically, we adopt aminimalistic approach, keeping the actions as simple as possible. The approachis inspired by the well-known STRIPS language for planning, which has beenadopted also in for data-centric processes [5]. More sophisticated forms of actions,as those in [9], can be seamlessly introduced.
Definition 12 (Action). A (parameterized) action over a D-typed persistencelayer hR, Ei is tuple hn, ~p, F+
, F
�i, where: (i) n is the action name; (ii) ~p is atuple of pairwise distinct typed variables from VD, denoting the action (formal)parameters. (iii) F
+ and F
� respectively represent a finite set of R-facts over~p, to be added to and deleted from the current database instance. Given a typedrelation R(D1, . . . ,Dn
) 2 R, an R-fact over ~p has the form R(y1, . . . , yn), suchthat for every i 2 {1, . . . , n}, y
i
is either a value o 2 �Di , or a variable x 2 ~p
with type(x) = Di
. An R-fact is an R-fact for some relation R from R. ⇤
To access the di↵erent components of an action ↵ = hn, ~p, F+, F
�i, we use a dotnotation: ↵·name = n, ↵·params = ~p, ↵·add = F
+, and ↵·del = F
�.We now turn to the semantics of actions. Actions are executed by grounding
their parameters to values. Given an action ↵ and a (parameter) substitution✓ for ↵, we call action instance ↵✓ the (ground) action resulting from ↵ bysubstituting its parameters with corresponding values, as specified by ✓.
Definition 13 (Action instance application). Let P = hR, Ei be aD-typedpersistence layer, I be a D-typed database instance I compliant with D, ↵ be anaction over P, and ✓ be a substitution for action·params. The application of ↵✓ onI, written apply(↵✓, I), is a database instance overR obtained as (I\F�
↵✓
)[F+↵✓
,where: (i) F
�↵✓
=S
R(~y)2↵·delR(~y)✓; (ii) F
+↵✓
=S
R(~y)2↵·addR(~y)✓. We say that↵✓ can be successfully applied to I if apply(↵✓, I) complies with P. ⇤
The application of an action instance amounts to ground all the facts containedin the definition of the action as specified by the given substitution, then ap-plying the update on the given database instance, giving priority to additionsover deletions (this is a standard approach, which unambiguously handles thesituation in which the same fact is asserted to be added and deleted).
The data logic simply exposes a set of queries and a set of actions that canbe used by the control layer to obtain data from the persistence layer, and toinduce updates on the persistence layer.
Definition 14 (Data logic layer). Given a D-typed persistence layer P, a D-typed data logic layer over P is a pair hQ,Ai, where: (i) Q is a finite set of FO(D)queries over P; (ii) A is a finite set of actions over P. ⇤
Example 2. We make the scenario of Example 1 operational, introducing a data logiclayer L over P. L exposes two queries to inspect the persistence layer:• Qe(e):-Emp(e) ^ ¬9t.Resp(e, t), to extract idle employees;• Qt(t, d):-Ticket(t, d), to extract tickets and their description.
In addition, L provides three main functionalities to manipulate tickets in persistencelayer: ticket registration, assignment/release, and logging. Such functionalities are re-alized through four actions (where, for simplicity, we blur the distinction between anaction and its name). The registration of a new ticket is managed by an action reg
that, given an integer t, and two strings e and d, (reg·params = ht , e, di, simultane-ously creates a ticket identified by t and described by d into the persistence layer, andassigns the employee identified by e to such ticket (thus making her busy):
reg·del = {Emp(e, idle)} reg·add = {Ticket(t , d),Resp(e, t)}
Two specular actions assign and release are exposed to assign or release a ticketto/from an employee, making her busy or idle. Both actions take as input a string forthe employee name and an integer for a ticket it (assign·params = release·params =he, ti), and update e by removing or adding that e is responsible of t:
release·del = assign·add = {Resp(e, t)} release·add = assign·del = ;
Finally, an action log with log·params = ht , e, di is exposed to flush the informationrelated to a ticket into a log table. The action erases all information about the ticket,and logs that it has been processed, also recalling its employee and description:
log·del = {Ticket(t , d),Resp(e, t)} log·add = {Log(t , e, d)}
2.3 Control Layer
The control layer employs a variant of CPNs to capture the process control flow,and how it interacts with an underlying persistence layer through the function-alities provided by the idata logic. The spirit is to conceptually ground CPNsby adopting a data-oriented approach. This is done by introducing dedicatedconstructs exploiting such functionalities, as well as simple, declarative patternsto capture the typical token consumption/creation mechanism of CPNs.
Before introducing the di↵erent constitutive elements of the control layertogether with their graphical appearance, we fix some preliminary notions. Weconsider the standard notion of amultiset. Given a set A, the set of multisets overA, written A
�, is the set of mappings of the form m : A ! N. Given a multisetS 2 A
� and an element a 2 A, S(a) 2 N denotes the number of times a appearsin S. Given a 2 A and n 2 N, we write a
n 2 S if S(a) = n. We also consider theusual operations on multisets. Given S1, S2 2 A
�: (i) S1 ✓ S2 (resp., S1 ⇢ S2)if S1(a) S2(a) (resp., S1(a) < S2(a)) for each a 2 A; (ii) S1 + S2 = {an |a 2 A and n = S1(a) + S2(a)}; (iii) if S1 ✓ S2, S2 � S1 = {an | a 2 A and n =S2(a)� S1(a)}; (iv) given a number k 2 N, k · S1 = {akn | an 2 S1}.2
Places. The control layer contains a finite set P of places, which in turn areclassified in two groups. On the one hand, so-called control places play the roleof standard places in classical Petri nets: they represent conditions/states of adynamic system. On the other hand, so-called view places are used as an interface
2 Hence, given a multiset S, we have 0 · S = ;.
Case variables: - ticket id - name of responsible employee
int⇥ string
![Page 50: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/50.jpg)
TransitionAtomic unit of work within the control layer
• Input data: obtained by • Consuming tokens from its input places • Reading tokens from its input view places
• To access tokens and their data: multisets of tuples of “matching” variables
• Data guard over the input variables
50
![Page 51: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/51.jpg)
TransitionAtomic unit of work within the control layer
• Output data: inputs + additional variables (external input) + ν variables (new ids)
• Output data used to • Bind to an action of the data logic, updating the
persistence layer • Produce tokens and insert them into the output
places
51
![Page 52: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/52.jpg)
Example
52
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
![Page 53: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/53.jpg)
Example
53
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
![Page 54: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/54.jpg)
Example
54
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
![Page 55: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/55.jpg)
Run!
55
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
EmpAndy
Marco
TicketResp Log
hAndyi
hMarcoi
![Page 56: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/56.jpg)
Run!
56
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
TicketResp Log
hAndyi
hMarcoi
⌫t = 1emp = Andy
descr = blah
EmpAndy
Marco
![Page 57: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/57.jpg)
Run!
57
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Ticket1 blah
RespAndy 1
Log
hMarcoi
EmpAndy
Marco
h1, Andyi
![Page 58: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/58.jpg)
Run!
58
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Ticket1 blah
RespAndy 1
Log
hMarcoi
EmpAndy
Marco
h1, Andyitid = 1
emp = Andy
![Page 59: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/59.jpg)
Run!
59
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Resp Log
hAndyi
hMarcoi
EmpAndy
Marco
Ticket1 blah
h1, blahi
h1, Andyi
![Page 60: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/60.jpg)
Run!
60
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Resp Log
hAndyi
hMarcoi
EmpAndy
Marco
Ticket1 blah
h1, blahi
h1, Andyi
⌫t = 5emp = Andy
descr = blah
![Page 61: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/61.jpg)
Run!
61
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Log
hMarcoi
EmpAndy
Marco
Ticket1 blah
2 blah
h1, blahi
h1, Andyi
RespAndy 2
h2, Andyi
h2, blahi
![Page 62: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/62.jpg)
Run!
62
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Log
hMarcoi
EmpAndy
Marco
Ticket1 blah
2 blah
h1, Andyi
RespAndy 2
h2, Andyi
tid = 1emp = Andy
h1, blahih2, blahi
![Page 63: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/63.jpg)
Run?
63
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Log
hMarcoi
EmpAndy
Marco
Ticket1 blah
2 blah
h1, Andyi
RespAndy 2
Andy 1
h2, Andyi
tid = 1emp = Andy
h1, blahih2, blahi
![Page 64: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/64.jpg)
Rollback FlowAccounts for the production and routing of tokens when the application of a ground action fails
• update ok: update committed on the DB, normal output flow used, rollback flow ignored
• update violates some constraint: rollback on the DB, rollback flow used, normal output flow ignored
The rollback flow can be used to model “undo” or “compensation” in the control layer when the persistence layer rejects an update
64
![Page 65: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/65.jpg)
Example: “Undo”
65
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
![Page 66: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/66.jpg)
Run!
66
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Log
hMarcoi
EmpAndy
Marco
Ticket1 blah
2 blah
h1, Andyi
RespAndy 2
Andy 1
h2, Andyi
tid = 1emp = Andy
h1, blahih2, blahi
![Page 67: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/67.jpg)
Run!
67
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pihtid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Idle Employees
register
(⌫t, emp, descr)
CreateTicket
Active tickets
release
(tid, emp)
Stall
assign
(tid, emp)
Awake
Stalled tickets
logData
(tid, emp, id)
ResolveTickets
h⌫t, empi htid, empi htid, empi
htid
,
e
m
p
iht
i
d
,
e
m
pi
htid, empi
hempi
htid, descri
htid
,
e
m
p
i
Fig. 2. The control layer of a db-net for ticket management. In CreateTicket, ⌫t is afresh input variable, and descr is an arbitrary input variable.
Example 3. Figure 2 shows the control layer of a db-net B, using the persistencelayer P defined in Example 1 and the data logic layer L defined in Example 2.2. Thecontrol layer realizes a simple ticket processing workflow, where tickets are created,manipulated, and finally resolved. In spite of its simplicity, B already shows manydistinctive features of our model. We intuitively describe the control layer moving fromleft to right and from top to bottom. Each case of this process is constituted by aticket and its responsible employee. A ticket is created by the CreateTicket transition,which requires the presence of an idle employee to be fired. Since this condition needsto inspect the persistence layer so as to retrieve idle employees, we model it through aview place associated to query Qe from L. Notice that if no employee is currently idle,then CreateTicket is not enabled. Upon firing CreateTicket for a given idle employee,a fresh ticket identifier is generated using fresh variable ⌫t, and a ticket description isobtained through the “external” input variable descr. All such data are bound to actionregister, which is applied when the transition fires. Among the e↵ects of register,there is one asserting that the selected employee becomes responsible for the newlycreated ticket. This indirectly implies that such an employee is not present anymore inthe view place for idle employees. The ticket id, together with its responsible employee,represent the case and its data. The two control places Active Tickets and Stalled
Tickets have color int ⇥ string, and model two distinct states in which tickets maybe. Such states are important only within the evolution of cases, and are therefore notpropagated to the underlying persistence layer. An active ticket may be “stalled” if theemployee is currently unable to resolve it. Executing the stall transition has a twofolde↵ect. Within the control layer, the ticket is moved from active to stalled. Withinthe persistence layer, its responsible employee is released. Interestingly, the relationof responsibility is now only recalled within the control layer. A stalled ticket may berevived, by inserting such a relation back into the persistence layer. This is captured bythe Awake transition, which mirrors the e↵ect of the Stall transition. However, thereis a particularly interesting aspect here. When a ticket t1 is stalled, its responsibleemployee e is released and becomes idle. She may be then selected as responsible of anewly created ticket t2. Due to the constraints present in P, the indirect e↵ect of thissituation is that t1 cannot be awaken unless t2 is either stalled or resolved. In fact,awakening t1 in a situation where t2 is active would violate the requirement that e isresponsible of at most one ticket. For this reason, we enrich the Awake transition witha rollback output arc, which brings back the ticket to the stalled state if it is awakenin the “wrong” moment. For example, if t1 is awaken while t2 is active, the application
Log
hMarcoi
EmpAndy
Marco
Ticket1 blah
2 blah
h1, Andyi
RespAndy 2
h2, Andyi
tid = 1emp = Andy
h1, blahih2, blahi
![Page 68: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/68.jpg)
Execution SemanticsInfinite-state relational transition system
• State: labeled with a DB-net snapshot <I,m> • I: DB instance for the persistence layer • m: marking of the control layer that properly fills view
places w.r.t. I
• Transition: firing of a control layer transition with a “legal” binding for the inscription variables
• All possible snapshots and all (infinitely many) bindings are considered
68
![Page 69: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/69.jpg)
…
Sources of Infinity
69……
…
………
……
……… …
Fixed initial snapshot
![Page 70: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/70.jpg)
…
Sources of Infinity
70……
…
………
……
……… …
Infinite-branching due to external inputs and new id generation
![Page 71: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/71.jpg)
…
Sources of Infinity
71……
…
………
……
……… …
Runs visiting infinitely many DBs/markings due to usage of external data
![Page 72: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/72.jpg)
72
![Page 73: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/73.jpg)
Formal Verification The Conventional, Propositional Case
Process control-flow
(Un)desired property73
![Page 74: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/74.jpg)
(Un)desired property
Finite-statetransition system
Propositionaltemporal formula|= �
Formal Verification The Conventional, Propositional Case
Process control-flow
74
![Page 75: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/75.jpg)
(Un)desired property
Finite-statetransition system
Propositionaltemporal formula|= �
Verification via model checking2007 Turing award:
Clarke, Emerson, Sifakis
Formal Verification The Conventional, Propositional Case
Process control-flow
75
![Page 76: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/76.jpg)
(Un)desired property
Formal Verification The Data-Aware Case
76
Process+Data
![Page 77: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/77.jpg)
(Un)desired property
First-ordertemporal formula|= �
Process+Data
Formal Verification The Data-Aware Case
Infinite-state, relational transition system 77
![Page 78: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/78.jpg)
(Un)desired property
First-ordertemporal formula|= �
?Formal Verification
The Data-Aware Case
78
Process+Data
Infinite-state, relational transition system [Vardi 2005]
![Page 79: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/79.jpg)
Why FO Temporal Logics• To inspect data: FO queries• To capture system dynamics: temporal
modalities• To track the evolution of objects: FO
quantification across states • Example:
It is always the case that every order is eventually either cancelled or paid
79
![Page 80: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/80.jpg)
Why FO Temporal Logics• To inspect data: FO queries• To capture system dynamics: temporal
modalities• To track the evolution of objects: FO
quantification across states • Example:
It is always the case that every order is eventually either cancelled or paid
80
G
✓8x.Order(x)
! F�State(x, cancelled) _ State(x, paid)
�◆
![Page 81: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/81.jpg)
Which logics?• First-order temporal logics with active domain
quantification
• Branching-time: μLa
• Linear-time: LTL-FOa
• Only initial constants can explicitly appear in the formulae
• Corresponding notions of bisimulation/trace equivalence
81
G(8s.Student(s) ! F(Retired(s) _Graduated(s))
AG(8o.Order(o) ^ Status(o, open) ! EF(mathitStatus(o, shipped))
![Page 82: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/82.jpg)
Atrue
false
BPMS and Data
Correct?
• BizAgi…
• YAWL…
82
![Page 83: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/83.jpg)
Atrue
false
BPMS and Data
Correct?
• BizAgi… not sure…
• YAWL… YES!
83
![Page 84: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/84.jpg)
The Good…DCDS are:
• Markovian: Next state only depends on the current state + input. Two states with identical DBs are bisimilar.
• Generic: FO/SQL (as all query languages) does not distinguish structures which are identical modulo uniform renaming of data objects.
—> Two isomorphic states are bisimilar84
![Page 85: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/85.jpg)
…the Bad…
85
![Page 86: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/86.jpg)
…the Bad…
86
Persistence layer
Control layer (without colors)
Data logic layer
![Page 87: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/87.jpg)
…and the UglySimulation of a 2-counter Minsky machine• Counter —> “size” of a unary relation
• Test counter for zero: query asserting that the counter relation is empty
• What matters is the # of tuples, not the actual values
87
New
Increment Decrement
![Page 88: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/88.jpg)
… and the Ugly (Again)
• By removing the persistence layer, DB-nets become as expressive as Petri nets with names
• A lot of undecidability results
• Recall that CTL model checking is undecidable already for P/T nets
88
![Page 89: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/89.jpg)
Problem Parameters
89
persistence layer
data logic layer
control layer
DB
ActionsQueries
View places Places Transitions
fetch update
populate trigger
ArcsRead arcsRollback arcs
Fig. 1. The conceptual components of db-nets
it employs workflow nets [1] for capturing the process control flow, without lever-aging the advanced capabilities of CPNs. Taking inspiration from [15], we thenpropose db-nets, a new, balanced formal model for data-aware processes, rootedin CPNs and relational databases. We rigorously describe the abstractions of-fered by the model, and formalize its execution semantics. We finally invite theresearch community to build on this new model, discussing its potential alongthree subjects: modeling, verification, and simulation.
2 The DB-Net Model
In our formal model, called db-net, we combine the distinctive features of CPNsand relational databases into a coherent framework, sketched in Figure 1. Themodel is structured in three layers:• persistence layer, capturing a full-fledged relational database with constraints,and used to store background data, and data that are persistent across cases.
• control layer, employing a variant of CPNs to capture the process control-flow,case data, and possibly the resources involved in the process execution.
• data logic layer, interconnecting in the persistence and the control layer.Thanks to the data logic, the control layer is supported in querying the un-derlying persistent data and tunes its own behavior depending on the obtainedanswers. Furthermore, the data logic may be exploited by the control layer to up-date the persistent data depending on the current state, the data locally carriedby tokens, and additional data obtained from the external world. We formalizethe framework layer by layer, from the bottom to the top.
2.1 Persistence Layer
The persistence layer maintains the relevant data in the domain of interest. Tothis end, we rely on standard relational databases equipped with constraints,in the spirit of [9]. First-order (FO) constraints allow for the formalization ofconventional database constraints, such as keys and functional dependencies, aswell as semantic constraints reflecting the domain of interest. Di↵erently from[9], though, we also consider data types, on the one hand resembling concretelogical schemas of relational databases (where table columns are typed), and onthe other reconciling the persistence layer with the notion of “color” in CPNs.
![Page 90: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/90.jpg)
Problem Parameters
90
persistence layer
data logic layer
control layer
DB
ActionsQueries
View places Places Transitions
fetch update
populate trigger
ArcsRead arcsRollback arcs
Fig. 1. The conceptual components of db-nets
it employs workflow nets [1] for capturing the process control flow, without lever-aging the advanced capabilities of CPNs. Taking inspiration from [15], we thenpropose db-nets, a new, balanced formal model for data-aware processes, rootedin CPNs and relational databases. We rigorously describe the abstractions of-fered by the model, and formalize its execution semantics. We finally invite theresearch community to build on this new model, discussing its potential alongthree subjects: modeling, verification, and simulation.
2 The DB-Net Model
In our formal model, called db-net, we combine the distinctive features of CPNsand relational databases into a coherent framework, sketched in Figure 1. Themodel is structured in three layers:• persistence layer, capturing a full-fledged relational database with constraints,and used to store background data, and data that are persistent across cases.
• control layer, employing a variant of CPNs to capture the process control-flow,case data, and possibly the resources involved in the process execution.
• data logic layer, interconnecting in the persistence and the control layer.Thanks to the data logic, the control layer is supported in querying the un-derlying persistent data and tunes its own behavior depending on the obtainedanswers. Furthermore, the data logic may be exploited by the control layer to up-date the persistent data depending on the current state, the data locally carriedby tokens, and additional data obtained from the external world. We formalizethe framework layer by layer, from the bottom to the top.
2.1 Persistence Layer
The persistence layer maintains the relevant data in the domain of interest. Tothis end, we rely on standard relational databases equipped with constraints,in the spirit of [9]. First-order (FO) constraints allow for the formalization ofconventional database constraints, such as keys and functional dependencies, aswell as semantic constraints reflecting the domain of interest. Di↵erently from[9], though, we also consider data types, on the one hand resembling concretelogical schemas of relational databases (where table columns are typed), and onthe other reconciling the persistence layer with the notion of “color” in CPNs.
Choice 1 Choice 2 …
Choice 1 undecidable boring boring
Choice 2 boring PTime boring
Choice 3 boring boring PSpace
… NP boring …
![Page 91: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/91.jpg)
Bottom Line• We want at least reachability
• We want robust conditions for decidability
• We would like to reuse conventional model checking techniques
• Infinitely many cases may appear in the life of the system, but only boundedly many coexist• Resources!
91
![Page 92: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/92.jpg)
Our Goal
92
First-ordertemporal formula|= �
Infinite-statetransition system
![Page 93: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/93.jpg)
Our Goal
93
First-ordertemporal formula|= �
Infinite-statetransition system
|= �
Finite-stateabstraction
Propositionaltemporal formula
‘
![Page 94: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/94.jpg)
Our Goal
94
First-ordertemporal formula|= �
Infinite-statetransition system
|= � Propositionaltemporal formula
‘If and only if
Finite-stateabstraction
![Page 95: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/95.jpg)
State-Boundedness [PODS 2013]
Put a pre-defined bound on the DB size and on the number of tokens moving around
• Resulting transition system: still infinite-state (even in the 1-bounded case)
• But: infinitely-many encountered values along a run cannot be “accumulated” in a single state
95
![Page 96: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/96.jpg)
Effect of state-boundedness
96
General State-bounded
μLa undecidable
LTL-FOa undecidable
![Page 97: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/97.jpg)
Effect of state-boundedness
97
General State-bounded
μLa undecidabledecidable
abstraction must depend on the formula!
LTL-FOa undecidable undecidable
![Page 98: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/98.jpg)
Effect of state-boundedness
98
General State-bounded
μLa undecidabledecidable
abstraction must depend on the formula!
LTL-FOa undecidable undecidable
Reason? FO quantification
across states.
![Page 99: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/99.jpg)
Effect of state-boundedness
99
General State-bounded
μLa undecidabledecidable
abstraction must depend on the formula!
LTL-FOa undecidable undecidable
Logic unable to isolate single runs/computations
![Page 100: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/100.jpg)
Logics with Persistent Quantification
• Intuition: control the ability of the logic to quantify across states
• Only objects that persist in the active domain of some node can be tracked
• When an object is lost, the formula trivializes to true or false
• E.g.: “guarded” until
unibz.itunibz.it
Persistence-Preserving µ-calculus (µLP
)In some cases, objects maintain their identity only if they persist in theactive domain (cf. business artifacts and their IDs).
. . .StudId : 123
. . .StudId : 123
. . .dismiss(123) newStud()ID() = 123
µLP restricts µLA to quantification over persistingobjects only, i.e., objects that continue to be live.
÷x.� ; ÷x.live(x) · �È≠Í�(x̨) ; live(x̨) · È≠Í�(x̨)[≠]�(x̨) ; live(x̨) · [≠]�(x̨) PDLLTL CTL
µL
µLP
µLA
µLFO
Example (“weak persistence”)‹X .(’x.live(x) · Stud(x) æ
µY .(÷y.live(y) · Grad(x, y) ‚ (live(x) æ È≠ÍY )) · [≠]X)Along every path, it is always true, for each student x, that there exists anevolution in which either x does not persist, or she eventually graduates.
Marco Montali Verification of Relational DCDSs PODS 2013 12 / 25
G(8s.Student(s) ! Student(s)U(Retired(s) _Graduated(s)))
100
![Page 101: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/101.jpg)
Effect of Persistent Quantification
101
General State-bounded
μLa undecidabledecidable
abstraction must depend on the formula!
μLp
LTL-FOa undecidable undecidable
LTL-FOp
![Page 102: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/102.jpg)
Effect of Persistent Quantification
102
General State-bounded
μLa undecidabledecidable
abstraction must depend on the formula!
μLp undecidable
LTL-FOa undecidable undecidable
LTL-FOp undecidable
![Page 103: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/103.jpg)
Effect of Persistent Quantification
103
General State-bounded
μLa undecidabledecidable
abstraction must depend on the formula!
μLp undecidabledecidable
formula-independent abstraction!
LTL-FOa undecidable undecidable
LTL-FOp undecidabledecidable
formula-independent abstraction!
![Page 104: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/104.jpg)
Pruning Infinite-Branching• Consider a DB-net snapshot • Fixed number of external inputs —> only
boundedly many isomorphic types relating the input objects and those appearing in the snapshot
• Input configurations in the same isomorphic type produce isomorphic snapshots
• Keep only one representative successor state per isomorphic type
The “pruned” transition system is finite-branching and bisimilar to the original one
104
![Page 105: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/105.jpg)
Example• External Input: single (new?) value • Current state: two objects (in DB and/or marking)
a,babc
de
105
![Page 106: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/106.jpg)
Example
a,babc
106
• External Input: single (new?) value • Current state: two objects (in DB and/or marking)
![Page 107: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/107.jpg)
Compacting Infinite Runs• Key observation: due to persistent quantification, the
logic is unable to distinguish local freshness from global freshness
• So we modify the transition system construction: whenever we need to consider a fresh representative object… • … Is there an old, recyclable object? —> use that one • … If not —> pick a globally fresh object This recycling technique preserves bisimulation!
107
![Page 108: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/108.jpg)
Compacting Infinite Runs
• [Calvanese et al, 2013]: if the system is size-bounded, the recycling technique reaches a point were no new objects are needed—> finite-state transition system
• N.B.: the technique does not need to know the value of the bound
108
![Page 109: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/109.jpg)
Recap
109
Prune Recycle
![Page 110: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/110.jpg)
Is My System State-Bounded?
• For a fixed k: decidable.
• For “some” bound: undecidable. • Classes of DB-nets for which state-boundedness is
decidable • Reasonable for the control layer, not for the data
logic [KR2014,_] • Sufficient, syntactic conditions [PODS2013,_]
[KR2014,_] • Methodologies to guarantee state-boundedness by
design [CIKM14,_] [STTT16,_] [FAOC16,_]110
![Page 111: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/111.jpg)
DB-Nets for Data Benchmarking• Data management: huge databases required to
test developed techniques
• Data are everywhere, but where are benchmarks?
• Synthetic data do not reflect real-world patterns
• Idea: apply CPN simulation techniques on top of DB-Nets • Result: synthetic DB indirectly mirroring the
process patterns111
![Page 112: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/112.jpg)
112
OBDI framework Query answering Ontology languages Mappings Identity Conclusions
Ontology-based data integration framework
. . .
. . .
. . .
. . .
Query
Result
Ontologyprovides
global vocabulary
and
conceptual view
Mappingssemantically link
sources and
ontology
Data Sourcesexternal and
heterogeneous
We achieve logical transparency in accessing data:
does not know where and how the data is stored.
can only see a conceptual view of the data.
Diego Calvanese (FUB) Ontologies for Data Integration FOfAI 2015, Buenos Aires – 27/7/2015 (7/52)
legacy data sources
conceptual data model
mapping
KAOS Project Knowledge-Aware Operational Support
trace, events, attrs… event annotations
![Page 113: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/113.jpg)
OBDI framework Query answering Ontology languages Mappings Identity Conclusions
Ontology-based data integration framework
. . .
. . .
. . .
. . .
Query
Result
Ontologyprovides
global vocabulary
and
conceptual view
Mappingssemantically link
sources and
ontology
Data Sourcesexternal and
heterogeneous
We achieve logical transparency in accessing data:
does not know where and how the data is stored.
can only see a conceptual view of the data.
Diego Calvanese (FUB) Ontologies for Data Integration FOfAI 2015, Buenos Aires – 27/7/2015 (7/52)
legacy data sources
conceptual data model
mapping
KAOS Project Knowledge-Aware Operational Support
trace, events, attrs… event annotations
113
OBDI framework Query answering Ontology languages Mappings Identity Conclusions
Ontology-based data integration framework
. . .
. . .
. . .
. . .
Query
Result
Ontologyprovides
global vocabulary
and
conceptual view
Mappingssemantically link
sources and
ontology
Data Sourcesexternal and
heterogeneous
We achieve logical transparency in accessing data:
does not know where and how the data is stored.
can only see a conceptual view of the data.
Diego Calvanese (FUB) Ontologies for Data Integration FOfAI 2015, Buenos Aires – 27/7/2015 (7/52)
processmining
![Page 114: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/114.jpg)
Log Annotations
114
1..*
*
Conferencecreationtime:DateTime
confname:String
Usercreationtime:DateTime
username:String
Papercreationtime:DateTime
title:String
ReviewRequestinvitationtime:DateTime
Reviewsubmissiontime:DateTime
Decisiondecisiontime:DateTime
outcome:Bool
UploadSubmitteduploadtime:DateTime
UploadAccepteduploadtime:DateTime
submittedto
1
*
organizerof
AcceptedPaper<<notime>>
*
reviewer
1
0..1
PhasD
1
0..1
RhasR
1
10..1 correspondsto
*
UhasP
1
*
AhasU
1
*1 for
author
1..*
*
by
1
*
USuploadbyU
creator
1
*
1*
UAuploadbyU
1
*
trace
event
event
eventevent
trace:followhasactivityname:“decision”timestamp:decisiontime
resource:followbytype:complete
attributes:outcome
trace:followhas&foractivityname:“review”
timestamp:submissiontimeresource:followRhasR&reviewer
type:complete
trace:followhasactivityname:“uploadsubmitted”
timestamp:uploadtimeresource:followUSuploadbyU
type:complete
trace:followhas&corr.toactivityname:“uploadaccepted”
timestamp:uploadtimeresource:followUAuploadbyU
type:complete
submittedto=BPM2015
![Page 115: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/115.jpg)
115
1..*
*
Conferencecreationtime:DateTime
confname:String
Usercreationtime:DateTime
username:String
Papercreationtime:DateTime
title:String
ReviewRequestinvitationtime:DateTime
Reviewsubmissiontime:DateTime
Decisiondecisiontime:DateTime
outcome:Bool
UploadSubmitteduploadtime:DateTime
UploadAccepteduploadtime:DateTime
submittedto
1
*
organizerof
AcceptedPaper<<notime>>
*
reviewer
1
0..1
PhasD
1
0..1
RhasR
1
10..1 correspondsto
*
UhasP
1
*
AhasU
1
*1 for
author
1..*
*
by
1
*
USuploadbyU
creator
1
*
1*
UAuploadbyU
1
*
trace
event
event
eventevent
trace:followhasactivityname:“decision”timestamp:decisiontime
resource:followbytype:complete
attributes:outcome
trace:followhas&foractivityname:“review”
timestamp:submissiontimeresource:followRhasR&reviewer
type:complete
trace:followhasactivityname:“uploadsubmitted”
timestamp:uploadtimeresource:followUSuploadbyU
type:complete
trace:followhas&corr.toactivityname:“uploadaccepted”
timestamp:uploadtimeresource:followUAuploadbyU
type:complete
submittedto=BPM2015
![Page 116: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/116.jpg)
Multiple Log Views
116
1..*
*
Conferencecreationtime:DateTime
confname:String
Usercreationtime:DateTime
username:String
Papercreationtime:DateTime
title:String
ReviewRequestinvitationtime:DateTime
Reviewsubmissiontime:DateTime
Decisiondecisiontime:DateTime
outcome:Bool
UploadSubmitteduploadtime:DateTime
UploadAccepteduploadtime:DateTime
submittedto
1
*
organizerof
AcceptedPaper<<notime>>
*
reviewer
1
0..1
PhasD
1
0..1
RhasR
1
10..1 correspondsto
*
UhasP
1
*
AhasU
1
*1 for
author
1..*
*
by
1
*
USuploadbyU
creator
1
*
1*
UAuploadbyU
1
*
trace
event
trace:followhasauthoractivityname:“decisionauthor”
timestamp:decisiontimeresource:followPhasD
type:complete
eventtrace:followby
activityname:“decisionchair”timestamp:decisiontimeresource:followPhasD
type:completeattributes:outcome
eventtrace:followhas&revieweractivityname:“review”
timestamp:submissiontimeresource:followRhasR&for
type:complete
eventtrace:followuploadby
activityname:“uploadsubmitted”timestamp:uploadtimeresource:followUhasP
type:complete
![Page 117: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/117.jpg)
117
1..*
*
Conferencecreationtime:DateTime
confname:String
Usercreationtime:DateTime
username:String
Papercreationtime:DateTime
title:String
ReviewRequestinvitationtime:DateTime
Reviewsubmissiontime:DateTime
Decisiondecisiontime:DateTime
outcome:Bool
UploadSubmitteduploadtime:DateTime
UploadAccepteduploadtime:DateTime
submittedto
1
*
organizerof
AcceptedPaper<<notime>>
*
reviewer
1
0..1
PhasD
1
0..1
RhasR
1
10..1 correspondsto
*
UhasP
1
*
AhasU
1
*1 for
author
1..*
*
by
1
*
USuploadbyU
creator
1
*
1*
UAuploadbyU
1
*
trace
event
trace:followhasauthoractivityname:“decisionauthor”
timestamp:decisiontimeresource:followPhasD
type:complete
eventtrace:followby
activityname:“decisionchair”timestamp:decisiontimeresource:followPhasD
type:completeattributes:outcome
eventtrace:followhas&revieweractivityname:“review”
timestamp:submissiontimeresource:followRhasR&for
type:complete
eventtrace:followuploadby
activityname:“uploadsubmitted”timestamp:uploadtimeresource:followUhasP
type:complete
![Page 118: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/118.jpg)
118
Conclusion
![Page 119: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/119.jpg)
Conclusion
• State-boundedness: a robust condition towards the effective verifiability of such systems
• Complexity: exponential in the “data that can be changed” • Same formal model for execution and verification
119
Marriage between processes and data is challenging, but necessary
DB-nets
![Page 120: Montali - DB-Nets: On The Marriage of Colored Petri Nets and Relational Databases](https://reader036.fdocuments.in/reader036/viewer/2022070602/58738c8a1a28ab272d8b6eb3/html5/thumbnails/120.jpg)
AcknowledgmentsAll coauthors of this research,
in particular
Diego Calvanese (UNIBZ)Giuseppe De Giacomo (Sapienza UNIROMA)
Alin Deutsch (UCSD)Marlon Dumas (Uni Tartu)
Fabio Patrizi (Sapienza UNIROMA)Andy Rivkin (UNIBZ)
120