Un sistema di persistenza per motori di workflow business-oriented BPMN

`
Universita degli Studi di Trieste

Dipartimento di Ingegneria e Architettura
Corso di Laurea in Ingegneria Informatica
Tesi di Laurea in Programmazione

Un sistema di persistenza
per motori di workﬂow
business-oriented BPMN

Candidato: Relatore:
Alessandro Segatto Chiar.mo Prof. Alberto Bartoli

Correlatori:
Ph.D. Carlos Kavka

Anno Accademico 2011-12 - Sessione straordinaria

.

Ai miei genitori, Mariateresa e Giorgio

Introduzione

L’integrazione ed automazione dei processi organizzativi e produt-
tivi in ambito aziendale viene spesso effettuata attraverso workflow
informatici la cui esecuzione ` orchestrata da appositi engine. Lo
e
standard Business Process Modelling Notation (BPMN) permette
di descrivere questi workflow in una forma adatta per supportarne
l’esecuzione. Lo standard si presta anche alla descrizione di work-
flow di tipo scientifico, che richiedono soluzioni specifiche e sono
essenziali per l’azienda ESTECO in cui ` stata sviluppata questa
e
tesi. Nella tesi si ` progettato e realizzato un modulo software per
e
estendere le funzionalit` dell’engine attualmente in sviluppo presso
a
l’azienda, in particolare per permettere la sospensione dell’esecu-
zione e il successivo ripristino di workflow scientifici.

Il primo capitolo indicher` quali sono gli obiettivi del lavoro svolto e quali
a
sono le particolarit` del problema da affrontare. Ai workflow scientifici `
a e
dedicata la prima parte del secondo capitolo. Si indagher` le caratteristiche
a
di questo mondo e successivamente si cercher` di comprendere in che mo-
a
do queste peculiarit` influenzino i requisiti di un engine e della persistenza.
a
Il prosieguo del secondo capitolo illustrer` le caratteristiche dello standard
a
“Business Process Modeling Notation”.

II

Il terzo capitolo, descriver` la struttura e il funzionamento del motore ESTE-
a
CO, esteso in questa tesi con le funzionalit` di persistenza. Successivamente
a
si spiegher` qual ` lo stato dell’arte nel campo dei motori BPMN in termi-
a e
ni di persistence, e questo verr` fatto tramite un’analisi del motore jBPM
a
prodotto dalla JBoss Community1 . In azienda il motore in questione era gi`
a
stato studiato in dettaglio perch´ ritenuto il migliore in considerazione delle
e
necessit` aziendali. Si contestualizzeranno inoltre le caratteristiche di questo
a
software, illustrando le motivazioni alla base delle scelte tecniche.
Successivamente si proceder` progettando un modulo in grado di soddisfa-
a
re i requisiti individuati, motivando le scelte progettuali eﬀettuate; conte-
stualmente si deﬁnir` anche un’interfaccia d’uso. Si concluder` con l’im-
a a
plementazione all’interno del motore del modulo, mostrando i pattern di
programmazione usati e le scelte tecniche fatte.

1
http://www.jboss.org

Indice

Introduzione I

1 Analisi Obiettivi e criticit`
a 1
1.1 Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Criticit` . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
a 3

2 Scientific workflows e BPMN 4
2.1 Scientific Workflows . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Business Process Modeling Notation . . . . . . . . . . . . . . 7
2.2.1 Componenti . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Rappresentazione XML . . . . . . . . . . . . . . . . . . 11

3 Engine da estendere 15
3.1 Struttura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Thread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4 Analisi persistenza in jBPM 21
4.1 Ambiente e configurazione . . . . . . . . . . . . . . . . . . . . 21
4.2 Analisi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3 Risultati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5 Progettazione modulo di persistenza 28
5.1 Interfaccia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2 Progettazione classi e metodi . . . . . . . . . . . . . . . . . . 30

INDICE IV

6 Implementazione 33
6.1 Ambiente e integrazione . . . . . . . . . . . . . . . . . . . . . 33
6.2 Pausa e ripartenza . . . . . . . . . . . . . . . . . . . . . . . . 34
6.3 Salvataggio e ripristino . . . . . . . . . . . . . . . . . . . . . . 35

7 Conclusioni 38

Bibliograﬁa 40

Elenco delle figure

2.1 I requisiti dei workflow . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Flow objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Data objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Connecting Objects . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Esempio di processo BPMN . . . . . . . . . . . . . . . . . . . 12

3.1 Struttura globale dell’engine ESTECO . . . . . . . . . . . . . 17
3.2 Struttura workflow Engine ESTECO . . . . . . . . . . . . . . 19

4.1 Persistenza su jBPM . . . . . . . . . . . . . . . . . . . . . . . 25

5.1 Oggetti contenenti lo stato dell’engine . . . . . . . . . . . . . . 31

Capitolo 1

Analisi Obiettivi e criticit`
a

1.1 Obiettivi
Lo scopo del lavoro svolto ` quello di creare un’implementazione software
e
in grado di estendere le funzionalit` di un engine BPMN1 , consentendo di
a
salvare il suo stato e ripristinarlo in seguito. Poich´ il prodotto finale ` stret-
e e
tamente connesso al motore, contestualmente al lavoro di implementazione
` necessario individuare delle metodologie che possano essere riutilizzate, sia
e
per adattare la parte inerente alla persistenza in caso di modifiche all’engine,
sia per capire come effettuare queste ultime.
I workflow scientifici, che sono il campo di utilizzo dell’engine da estendere,
si caratterizzano in modo marcato rispetto ai workflow generici. Un ana-
lisi pi` approfondita verr` fatta in seguito, per adesso basti sapere che si
u a
distinguono dagli altri per l’elevata mole di dati e di calcoli necessari per l’e-
secuzione. Queste caratteristiche si riflettono sulle feature che l’engine deve
implementare. Sono infatti richieste:

1. Sofisticata gestione degli errori [1]

2. Scalabilit` [5]
a
1
http://www.bpmn.org

1.1 Obiettivi 2

Queste due caratteristiche sono necessarie al fine di rendere accettabili i tempi
di esecuzione e di non sprecare risorse. La persistenza si inserisce all’interno
delle feature di gestione degli errori ma deve comunque tenere conto della
necessit` di scalabilit`.
a a
Gli scopi della nuova funzionalit` sono molteplici: il pi` banale ` quello di
a u e
consentire di sospendere temporaneamente un flusso di esecuzione, salvan-
do tutte le informazioni in modo non volatile e riprendere l’esecuzione in
un secondo momento. Raggiunto questo obiettivo si pu` pensare anche alla
o
persistenza come mezzo per aumentare la solidit` dell’engine; costituisce in-
a
fatti il passo fondamentale verso la creazione di un engine in grado di gestire
eventuali cedimenti da parte dei servizi dei quali fa uso, siano essi software
(ad es. il sistema operativo), oppure hardware. L’idea ` quella di ripristinare
e
lo stato dell’engine precedente al fallimento, evitando di dover ricominciare
l’esecuzione dall’inizio.
Al fine di rendere possibile un utilizzo quanto pi` ampio delle funzionalit`
u a
create, ` necessario che i vincoli d’uso e funzionamento siano minimi. Ope-
e
rativamente questa necessit` si traduce nella possibilit` di salvare lo stato
a a
del motore il maggior numero di volte possibile nel corso di un’esecuzione,
con un costo minimo in termini di tempo impiegato. Una volta scelte le
informazioni da salvare, il salvataggio deve consentire, a partire da queste,
di riprendere l’esecuzione per poter essere considerato utile. Uno stato con
queste caratteristiche verr` chiamato valido.
a
Per quanto riguarda le prestazioni del salvataggio, ` importante scegliere qua-
e
li dati salvare, al fine di ottenere tutte le informazioni necessarie, senza per`
o
introdurre ridondanze. Un ulteriore obiettivo ` costituito dalla volont` di
e a
aumentare il meno possibile la complessit` interna dell’engine, implementan-
a
do inoltre soluzioni che non precludano eventuali evoluzioni a cui il motore
potrebbe essere sottoposto.
Anche la complessit` d’utilizzo dell’engine deve essere quanto pi` contenuta;
a u
a tal fine ci si prefigge l’obiettivo di mettere a disposizione dell’utente un’in-

1.2 Criticit`
a 3

terfaccia che consenta l’utilizzo del motore dotato di persistenza nascondendo
la complessit` del funzionamento agli occhi dell’utilizzatore.
a

1.2 Criticit`
a
Il principale aspetto critico riguardante la persistenza dello stato di un engine
riguarda la coerenza dei dati. Si deve garantire che il salvataggio possa essere
iniziato e completato mentre il motore si trova in uno stato valido, altrimenti
´
si rischia di ottenere un’immagine non utilizzabile. E necessario che i dati da
salvare non siano modificati durante tutto il processo di salvataggio.
Il secondo aspetto riguarda la difficolt` di procedere ad un arresto dell’engi-
a
ne che non solo porti ad uno stato adatto al salvataggio, ma anche che sia il
pi` rapido possibile. In presenza di molti thread il soddisfacimento dei due
u
requisiti non ` banale.
e
Una necessit` dei workflow scientifici ` quella di essere riproducibili; ` quindi
a e e
necessario che le modifiche introdotte non alterino in alcun modo il flusso
d’esecuzione.
Le funzionalit` di persistenza possono inoltre risultare particolarmente in-
a
vasive, sia perch´ potrebbero essere necessarie modifiche alla logica di fun-
e
zionamento, sia perch´ richiedono del codice all’interno dell’engine, contri-
e
buendo ad aumentarne la complessit`. Modifiche troppo invasive potrebbero
a
addirittura limitare le possibili evoluzioni dell’engine.

Capitolo 2

Scientific workflows e BPMN

2.1 Scientific Workflows
In questa sezione si vuole descrivere brevemente il concetto di workflow scien-
tifico, di workflow management system e di workflow manager al fine di chia-
rire il contesto all’interno del quale si ` svolto il lavoro di tesi. Si pu` definire
e o
un workflow come una sequenza di passi concatenati con il fine di gestire e
ottimizzare, tramite un’astrazione, il lavoro reale svolto da una persona o da
un gruppo di persone. Solitamente il flusso descritto riguarda la creazione
di un documento o di un progetto. Definiamo anche il processo, che costitui-
sce una nozione pi` specifica rispetto a quella di workflow: indica infatti un
u
flusso con input, output e scopo maggiormente definiti rispetto a quelli del
workflow generico. Un workflow pu` contenere pi` processi al suo interno.
o u
Durante l’esecuzione di un workflow le informazioni o i processi operativi
sono distribuiti tra gli utenti del sistema, con la finalit` di compiere una de-
a
terminata azione in base a quanto specificato.
Un workflow scientifico ` una specializzazione di workflow che descrive un
e
processo computazionale, usato per modellare ed automatizzare un esperi-
mento scientifico. I workflow scientifici sono solitamente rappresentati come
un grafo diretto (o orientato) con componenti costituite dai nodi task, che

2.1 Scientific Workflows 5

rappresentano specifiche computazioni o elaborazioni di dati. Si differenziano
da un classico programma per computer poich´ i task in un scientific workflow
e
sono tipicamente definiti come dei componenti di alto livello. In esempio, un
singolo task potrebbe corrispondere all’esecuzione di un programma di tipo
CAD/CAE, oppure all’esecuzione di un risolutore definito in un ambiente
di calcolo (ad es. MATLAB). I workflow scientifici sono, al giorno d’oggi,
largamente utilizzati in chimica, fisica, scienze e tanti altri campi scientifi-
ci. Riportiamo, nella figura2.1 e in legenda un elenco delle caratteristiche
richieste dai workflow ed in particolare dagli scientific workflows[5, 3].

Workflows

1. 2. Scientific
Workflows
3. 4. 8. 9. 10. 11.
5. 6. 12. 13. 14. 15.
16. 17.
7.

Figura 2.1: I requisiti dei workflow

1. Human Tasks: un task che deve essere eseguito da un attore umano.

2. Transazionalit`.
a

2.1 Scientific Workflows 6

3. Gestione degli errori a livello di workflow: viene specificato nel workflow
come affrontare determinati tipi di errore (es. timeout).

4. Standardizzazione.

5. Qualit` del servizio.
a

6. Gestione degli eventi esterni.

7. Concetti di modelli di processo e di istanze di processo.

8. Automazione.

9. Monitoraggio.

10. Scalabilit`.
a

11. Controllo di flusso.

12. Flessibilit`.
a

13. Supporto grid/cluster.

14. Elaborazione tramite pipeline.

15. Riproducibilit`.
a

16. Flusso dei dati esplicito.

17. Gestione di grandi quantit` di dati.
a

Un workflow management system permette di definire, di creare e di ge-
stire l’esecuzione di workflow attraverso l’utilizzo di software in esecuzione
all’interno di uno o pi` motori di workflow. Un workflow manager (in que-
u
sta tesi chiamato engine) si occupa di interpretare la definizione formale di
un processo, con l’obiettivo di interagire con le componenti del sistema che
prendono parte al processo, gestendone lo stato ed il coordinamento delle
attivit`. Tale definizione viene inserita come input del sistema e pu` essere
a o

2.2 Business Process Modeling Notation 7

scritta in un linguaggio standard, come ad esempio XML, o in un linguaggio
proprietario.Un workflow management system deve essere in grado di moni-
torare ed eseguire processi che compongono il workflow; questa esecuzione
pu` essere automatica ed indipendente dall’utente che in questo modo occu-
o
pa unicamente il ruolo di pianificatore del flusso di lavoro e di utilizzatore
del risultato del calcolo[7].

2.2 Business Process Modeling Notation
Le aziende necessitano di un linguaggio in grado di consentire la modella-
zione e la rappresentazione grafica dei workflow e contestualmente renderne
agevole la condivisione. L’Object Management Group 1 (OMG) per soddisfa-
re questa necessit` ha sviluppato un linguaggio, chiamato Business Process
a
Modeling Notation (BPMN). La notazione grafica facilita la comprensione
delle collaborazioni e delle transazioni aziendali, consentendo alle imprese di
comprendere se stesse e gli attori del loro modello d’affari. I workflow sono
rappresentati come flowchart, riprendendo lo stile degli UML2 activity dia-
grams.
Il BPMN nasce come standard per la rappresentazione grafica dei workflow,
ma successivamente si occupa anche di descrivere in maniera non grafica i
processi, al fine di renderne possibile l’esecuzione e lo scambio. Si pone quin-
di nel ruolo di intermediario tra la fase di elaborazione dei processi e quella
di implementazione. A partire dalla versione 2.0, BPMN ` stato dotato di
e
un metamodello in grado di fornire una definizione formale del processo e
di tutte le azioni e componenti che lo compongono. Sono infatti stati ag-
giunti dei diagrammi UML che mostrano le caratteristiche e le relazioni dei
componenti. Risulta quindi possibile utilizzare il BPMN per rappresentare,
1
L’OMG ` un’associazione internazionale, aperta a tutti e non-profit. Ha come ambito
e
d’interesse il mondo dell’informatica: sviluppa infatti standard di integrazione tra aziende
che interessano numerosi campi tecnologici. http://www.omg.org
2
http://www.uml.org


implementare ed infine eseguire i processi. L’esecuzione viene effettuata a
partire da una descrizione del processo in formato XML. Nel file trovano
posto tutte le informazioni necessarie all’esecuzione, in particolare la descri-
zione del processo e i dati necessari all’esecuzione. Il metamodello, attraverso
la rappresentazione XML del processo, ne garantisce la riproducibilit` e la
a
coerenza dei risultati.

2.2.1 Componenti
Di seguito mostreremo gli oggetti utilizzati dalla specifica BPMN per svol-
gere il suo ruolo di descrizione dei processi. I processi possono contenerne
degli altri (che prendono il nome di sottoprocessi) e collaborare con altri. I
componenti utilizzati dal BPMN sono:

1. Flow Objects

2. Data Objects

3. Connecting Objects

4. Swimlanes

5. Artifacts

I primi tre sono necessari alla definizione del processo, e ne regolano le azio-
ni, il flusso d’esecuzione e quello dei dati. Gli ultimi due invece contribui-
scono a mostrare informazioni addizionali del processo, che per` non sono
o
direttamente legate alla logica d’esecuzione. Di seguito si riporta una breve
panoramica dei principali elementi messi a disposizione dallo standard, divisi
per categorie.


Flow Objects

Nella categoria Flow objects (Fig. 2.2) sono raggruppati tutti gli elementi
principali di un workflow, quali event, activity e gateway. Gli elementi event
si riferiscono ad eventi che intervengono durante l’esecuzione del processo,
consentono di rappresentare molti degli avvenimenti che accadono durante
l’esecuzione di un processo: l’inizio di un’attivit`, la fine di un’attivit`, il
a a
cambio di stato di un documento, la ricezione di un messaggio, etc. Gli
elementi activity rappresentano il punto del processo dove un lavoro viene
eseguito; nel caso di lavoro atomico si parla di elementi task, mentre nel
caso di un lavoro scomponibile si parla di elementi sub-process. Gli ele-
menti gateway sono usati per controllare il flusso di esecuzione del processo,
consentendo di porre condizioni complesse.

(a) Events (b) Activities (c) Gateways

Figura 2.2: Flow objects

Data Objects

La categoria Data (Fig. 2.3) contiene tutte le tipologie di dati gestiti in
un workflow, suddivisi in data object, data input, data output e data stores.
Gli elementi data object corrispondono alle variabili di processo, mentre gli
elementi data stores fanno riferimento a qualsiasi dato persistente.

(a) Data object (b) Data input (c) Data output (d) Data store

Figura 2.3: Data objects


Connecting Objects

La categoria connecting objects (Fig. 2.4) contiene tutti gli elementi che
collegano fra loro i flow objects, suddivisi in sequence flows, message flows,
associations, data associations. Gli elementi sequence flows collegano gli
elementi del workflow che entrano nel flusso di esecuzione del processo. Gli
elementi data associations collegano gli elementi della categoria data agli
elementi della categoria flow objects, quindi definiscono il flusso dati del
processo. Gli elementi message flows collegano pools oppure flow objects
contenuti al loro interno e permettono di inviare dati esternamente al flusso
di esecuzione di un partecipante.

(a) Sequence flow (b) Message Flows (c) Associations

Figura 2.4: Connecting Objects

Swimlanes

Gli elementi della categoria swimlanes permettono di raggruppare gli elemen-
ti del workflow afferendoli ai diversi partecipanti; si distinguono in pools e
lanes. Gli elementi pool rappresentano i partecipanti ad una collaborazione.
Gli elementi lanes corrispondono a partizioni del processo e vengono usati
per organizzare e catalogare le activity.

Artifacts

Gli artifacts sono elementi che forniscono informazioni addizionali ad ele-
menti o al processo, distinti in group e text annotation. Gli elementi group
sono elementi grafici che permettono di raggruppare elementi che fanno par-
te di una stessa categoria. Gli elementi text annotation vengono collegati
ad elementi del workflow tramite associations e vengono usati per fornire
informazioni testuali utili per comprendere il diagramma.


2.2.2 Rappresentazione XML
Ogni workflow ` definito da una specifica rappresentazione grafica e da un re-
e
lativo documento XML basato sul BPMN 2.0 Schema definition. La presenza
del documento XML consente di raggiungere un duplice obiettivo: consente
infatti sia di trasportare i processi da un ambiente di design all’altro, sia di
rendere eseguibile il processo. Infatti un eventuale engine che si occupi dell’e-
secuzione di un processo carica tutte le informazioni relative a quest’ultimo
a partire dal documento XML. In questo senso si pu` parlare della rappre-
o
sentazione XML come unico elemento di definizione del processo da eseguire.
Di seguito riportiamo un esempio di rappresentazione XML per un processo.
L’esempio ` tratto da un documento ufficiale dell’OMG [8] e tratta il pro-
e
cesso di acquisto di un bene da parte di un committente. Si inizia con un
primo task che consiste nel verificare la quotazione del bene da acquistare;
successivamente la proposta d’acquisto viene sottoposta al giudizio di un su-
periore. In caso di giudizio positivo si procede con la gestione dell’ordine e
della spedizione. Al termine di entrambe i task, un altro attore provveder`
a
a revisionare il tutto.


Figura 2.5: Esempio di processo BPMN

1 <? xml version = " 1.0 " encoding = " UTF -8 " ? >
2 < definitions id = " Definition "
3 t ar ge tN a me sp ac e = " http: // www . example . org / Us er Ta s kE xa mp l e "
4 typeLanguage = " http: // www . w3 . org /2001/ XMLSchema "
5 e x p r e s s i o n L a n g u a g e = " http: // www . w3 . org /1999/ XPath "
6 xmlns = " http: // www . w3 . org /2001/ XMLSchema "
7 xmlns = " http: // www . omg . org / spec / BPMN /20100524/ MODEL "
8 xmlns:tns = " http: // www . example . org / U se r Ta sk E xa mp le " >
9 < resource id = " r eg io na l Ma na g er " name = " Regional Manager " >
10 < r e s o u r c e P a r a m e t e r id = " buyerName " isRequired = " true " name = " Buyer Name "
type = " xsd:string " / >
11 < r e s o u r c e P a r a m e t e r id = " region " isRequired = " false " name = " Region "
12 </ resource >
13 < resource id = " d e p a r t m e n t a l R e v i e w e r " name = " Departmental Reviewer " >
14 < r e s o u r c e P a r a m e t e r id = " buyerName " isRequired = " true " name = " Buyer Name "
15 </ resource >
16 < collaboration id = " B u y e r C o l l a b o r a t i o n " name = " Buyer Collaboration " >
17 < participant id = " B u y e r P a r t i c i p a n t " name = " Buyer "
processRef = " BuyerProcess " / >
18 </ collaboration >
19 <! -- Process definition -- >
20 < process id = " BuyerProcess " name = " Buyer Process " >
21 < laneSet id = " BuyerLaneSet " >
22 < lane id = " BuyerLane " >
23 < flowNodeRef > StartProcess </ flowNodeRef >
24 < flowNodeRef > Q u o t a t i o n H a n d l i n g </ flowNodeRef >
25 < flowNodeRef > ApproveOrder </ flowNodeRef >
26 < flowNodeRef > O r d e r A p p r o v e d D e c i s i o n </ flowNodeRef >
27 < flowNodeRef > T e r m i n a t e P r o c es s </ flowNodeRef >
28 < flowNodeRef > O r d e r A n d S h i p m en t </ flowNodeRef >
29 < flowNodeRef > OrderHandling </ flowNodeRef >


30 < flowNodeRef > S h i p m e n t H a n d l in g </ flowNodeRef >
31 < flowNodeRef > O r d e r A n d S h i p m e n t M e r g e </ flowNodeRef >
32 < flowNodeRef > ReviewOrder </ flowNodeRef >
33 < flowNodeRef > EndProcess </ flowNodeRef >
34 </ lane >
35 </ laneSet >
36 < startEvent id = " StartProcess " / >
37 < sequenceFlow sourceRef = " StartProcess " targetRef = " Q u o t a t i o n H a n d l i n g " / >
38 < task id = " Q u o t a t i o n H a n d l i n g " name = " Quotation Handling " / >
39 < sequenceFlow sourceRef = " Q u o t a t i o n H a n d l i n g " targetRef = " ApproveOrder " / >
40 < userTask id = " ApproveOrder " name = " ApproveOrder " >
41 < potentia lOwner >
42 < resourceRef > t n s : r e g i o n a l M a n a g e r </ resourceRef >
43 < r e s o u r c e P a r a m e t e r B i n d i n g parameterRef = " tns:buyerName " >
44 < f o r m a l E x p r e s s i o n > getDataInput ( ’ order ’) / address / name
</ f o r m al E x p r e s s i o n >
45 </ r e s o u r c e P a r a m e t e r B i n d i n g >
46 < r e s o u r c e P a r a m e t e r B i n d i n g parameterRef = " tns:region " >
47 < f o r m a l E x p r e s s i o n > getDataInput ( ’ order ’) / address / country
</ f o r m al E x p r e s s i o n >
49 </ potent ialOwner >
50 </ userTask >
51 < sequenceFlow sourceRef = " ApproveOrder " targetRef = " O r d e r A p p r o v e d D e c i s i o n " / >
52 < e x c l u s i v e G a t e w a y id = " O r d e r A p p r o v e d D e c i s i o n "
g a t e w a y D i r e c t io n = " Diverging " / >
53 < sequenceFlow sourceRef = " O r d e r A p p r o v e d D e c i s i o n "
targetRef = " O r d e r A nd S h i p m e n t " >
54 < c o n d i t i o n E x p r e s s i o n > Was the Order Approved ? </ c o n d i t i o n E x p r e s s i o n >
55 </ sequenceFlow >
56 < sequenceFlow sourceRef = " O r d e r A p p r o v e d D e c i s i o n "
targetRef = " T e r m i n at e P r o c e s s " >
57 < c o n d i t i o n E x p r e s s i o n > Was the Order NOT Approved ? </ c o n d i t i o n E x p r e s s i o n >
58 </ sequenceFlow >
59 < endEvent id = " T e r m i n a t e P r o c e s s " >
60 < t e r m i n a t e E v e n t D e f i n i t i o n id = " Term inateEv ent " / >
61 </ endEvent >
62 < p ar al le l Ga te wa y id = " O r d e r A n d S h i p m en t " g a t e w a y D i r e c t i o n = " Diverging " / >
63 < sequenceFlow sourceRef = " O r d e r A n d S hi p m e n t " targetRef = " OrderHandling " / >
64 < sequenceFlow sourceRef = " O r d e r A n d S hi p m e n t " targetRef = " S h i p m e n t H a n d l i n g " / >
65 < task id = " OrderHandling " name = " Order Handling " / >
66 < task id = " S h ip m e n t H a n d l i n g " name = " Shipment Handling " / >
67 < sequenceFlow sourceRef = " OrderHandling "
targetRef = " O r d e r A n d S h i p m e n t M e r g e " / >
68 < sequenceFlow sourceRef = " S h i p m e n t H an d l i n g "
targetRef = " O r d e r A n d S h i p m e n t M e r g e " / >


69 < p ar al le l Ga te wa y id = " O r d e r A n d S h i p m e n t M e r g e "
g a t e w a y D i r e c t io n = " Converging " / >
70 < sequenceFlow sourceRef = " O r d e r A n d S h i p m e n t M e r g e " targetRef = " ReviewOrder " / >
71 < userTask id = " ReviewOrder " name = " Review Order " >
72 < potentia lOwner >
73 < resourceRef > t n s : d e p a r t m e n t a l R e v i e w e r </ resourceRef >
74 < r e s o u r c e P a r a m e t e r B i n d i n g parameterRef = " tns:buyerName " >
75 < f o r m a l E x p r e s s i o n > getDataInput ( ’ order ’) / address / name </ f o r m a l Ex p r e s s i o n >
77 </ potent ialOwner >
78 </ userTask >
79 < sequenceFlow sourceRef = " ReviewOrder " targetRef = " EndProcess " / >
80 < endEvent id = " EndProcess " / >
81 </ process >
82 </ definitions >

Come si pu` vedere dal documento XML la definizione che viene data del
o
processo ` divisa in pi` parti. Nella prima vengono definite le risorse che
e u
collaborano al processo. Nella seconda invece vengono definiti i vari nodi
del workflow, esplicitando la loro appartenenza al processo ed eventualmente
ad una lane. Infine vengono descritti i vari componenti nel dettaglio, in
ordine sequenziale. Vengono descritte le loro connessioni, le risorse di cui
fanno uso, i dati necessari all’esecuzione. La vastit` dei componenti e delle
a
possibilit` offerte da BPMN rende improponibile trattarli tutti in questo
a
documento. Si ritiene per` che il seppur limitato sottoinsieme di componenti
o
introdotto sia in grado di fornire un’indicazione di massima sulle potenzialit`
a
del linguaggio. I processi modellati per mezzo del BPMN e in particolare della
rappresentazione XML sono l’input per gli engine che accettano il BPMN
come linguaggio di funzionamento.

Capitolo 3

Engine da estendere

3.1 Struttura
L’engine in questione ` stato sviluppato all’interno dell’azienda ESTECO, ed
e
era, al momento dell’inizio di questo lavoro, la versione pi` aggiornata in pos-
u
sesso dell’azienda. La struttura ` rappresentata in figura 3.1. A partire da un
e
file di tipo XML l’engine ne effettua il parsing e genera un modello che rap-
presenta il processo per mezzo di oggetti Java. Esistono due tipi di modello.
Uno ` statico, prende il nome di knowledge base, e rappresenta il corrispettivo
e
diretto del processo descritto in BPMN e non cambia durante l’esecuzione,
l’altro invece, chiamato process instance rappresenta lo stato dell’esecuzione
e ad ogni avanzamento nell’esecuzione del workflow corrisponde una modifica
in questo modello. Nello schema (Fig. 3.1, in alto) ` rappresentato come un
e
albero dove ogni nodo ` figlio dei nodi da cui dipende: il nodo di partenza
e
del workflow risulta quindi essere la radice.
Tutte le azioni di modifica del modello dinamico vengono eseguite a partire
da una coda1 chiamata workflow event queue che contiene gli eventi che fa-
ranno avanzare da uno stato all’altro il motore. Un evento viene eseguito e
poi attiva il seguente, mettendolo in coda. Tutti i calcoli richiesti dagli event
1
La coda ` una struttura dati gestita con un criterio FIFO.
e

3.1 Struttura 16

e dai gateway vengono elaborati tramite questa coda. Per le activity invece
` stata adottata una soluzione diversa. In ESTECO si ` scelto infatti di
e e
eseguirle all’esterno dell’engine, sia perch´ potrebbero richiedere risorse non
e
disponibili all’engine, sia perch´ con la struttura scelta ` possibile distribuire
e e
il carico d’esecuzione. Infatti le activity da eseguire vengono aﬃdate a un
work manager, che si occupa di impacchettarle all’interno di un messaggio
(work message), contenente i dati di input e le speciﬁche di esecuzione, e di
inserirle in un’altra coda. Su questa coda, chiamata work message queue,
con una logica produttore-consumatore sono posti in ascolto dei work job
engine che sono in grado di eseguire queste activity; al termine dell’esecu-
zione di queste, il risultato viene posto nuovamente sulla coda (Fig. 3.1, in
basso). Il work manager si occupa di gestire tutte le comunicazioni con la
work message queue sia nelle operazioni di invio che in quelle di ricezione.
La coda contenente i work message al momento ` una normale coda Java,
e
ma ` prevista l’adozione di una coda dotata di transazionalit` e persistenza.
e a

3.1 Struttura 17

Workflow Engine
Process Instance

Workflow Event Queue
Work
Manager
Runnable Runnable Runnable

Work Item Message
X=3 X=?
(WIM)

Work Message
WIM
WIM WIM WIM WIM
Queue

Work Job Engine Work Job Engine

Job 1 Job 2 Job 3 Job 1 Job 2

Figura 3.1: Struttura globale dell’engine ESTECO

3.1 Struttura 18

La parte di engine sulla quale si richiedeva di intervenire con il modulo `
e
quella che si pone tra il modello statico del processo e la coda con i work
message. Per poter capire le problematiche e la soluzione proposta ` neces-
e
sario entrare pi` nel dettaglio della struttura di quella parte di engine che
u
viene chiamata workflow engine (Fig. 3.2). Questa area inizia con il modello
statico del processo e finisce con il work manager. Il modello statico ` imple-
e
mentato dall’oggetto knowledge base; a partire da questo viene creata una
sessione (knowledge session) che contiene le risorse globali del processo e fa
da punto di collegamento tra le entit` dell’engine. Infatti ` questo oggetto,
a e
tramite la process runtime, ad offrire tutti i servizi che servono per l’esecu-
zione, tra cui il work manager. La process instance ` l’oggetto contenente
e
lo stato dell’esecuzione e la workflow event queue contiene l’azione che deve
essere eseguita per procedere nell’esecuzione. La figura 3.2 illustra in modo
grafico le relazioni tra gli oggetti.
La process instance al suo interno contiene una rappresentazione statica del
processo, unita a una struttura dati che indica a che punto ` l’esecuzione
e
del workflow. Gli eventi che si possono trovare nella workflow event queue
invece, sono riferiti al punto d’esecuzione con lo scopo di farlo avanzare.

3.1 Struttura 19

Workflow Engine

KnowledgeBase Servizi

Definizione
Statica del
Processo

Knowledge Process
Session Runtime

Process Instance

Work
Definizione Manager
dinamica del
Processo

Workflow Event Queue

Figura 3.2: Struttura workﬂow Engine ESTECO

3.2 Thread 20

3.2 Thread
L’engine ha un funzionamento basato sul multithreading. Comprendere come
i thread interagiscono e gestiscono l’accesso alle risorse comuni ` importante,
e
soprattutto nell’ottica di sviluppare uno spegnimento ordinato dell’engine.
La spiegazione che seguir` fa riferimento sempre alla figura 3.1.
a
Il primo thread da considerare ` associato alla workflow event queue. Svolge
e
il ruolo di consumatore nei confronti degli eventi presenti in coda. Atten-
de che ve ne siano, ne carica il primo e lo esegue. Gli eventi in questione
implementano un’interfaccia che ne consente l’esecuzione senza la necessit`
a
di conoscerne i dettagli. Tutte le modifiche alla process instance vengono
effettuate da questo thread, per evitare di dover introdurre meccanismi che
regolino l’accesso concorrente a questa risorsa.
Un secondo thread ` legato al work manager. Anche lui ha un ruolo di consu-
e
matore, e in particolare resta in attesa di un work message sulla work message
queue. Quando trova un work message da ritirare analizza il contenuto e fa
in modo che nella work event queue venga inserita una action per allineare
la process instace al risultato ricevuto. Un work message presente in coda
da ritirare ` il frutto di un’esecuzione da parte di un work job engine. Il
e
processo di ricezione di un work message ` diviso in due fasi. Nella prima si
e
associa il work message ricevuto con l’activity che aveva dato il via all’esecu-
zione. Successivamente si inserisce un evento nella workflow event queue in
grado di far procedere l’esecuzione, alla luce del risultato ottenuto. Queste
operazioni richiedono che il work manager contenga delle informazioni sulla
process instance, anche se non accede mai direttamente a quest’ultima, ma
la modifica solo in maniera indiretta.
I work job engine a loro volta possiedono due thread ciascuno: il primo si
occupa di stare in ascolto sulla work message queue in attesa di un job da
eseguire, il secondo esegue un job quando viene prelevato.

Capitolo 4

Analisi persistenza in jBPM

In questo capitolo si analizzer` il funzionamento e la struttura della parte di
a
persistenza del motore jBPM prodotto dalla JBoss Community1 insieme ad
altri software che compongono una suite per la gestione dei processi BPMN.

4.1 Ambiente e configurazione
Nel pacchetto oltre al motore sono inclusi numerosi altri tool, con l’obiettivo
di potenziare i servizi offerti dal motore e di consentire un utilizzo completo
delle sue funzionalit`. Si ` fatto uso dei seguenti tool:
a e

1. Editor jBPM per process modelling (Web Based e Eclipse Plugin)

2. Human Tasks (Server, Client Web, Eclipse Plugin)

Le caratteristiche annunciate dal produttore e che sono state verificate, sono:

1. Distinzione in 3 livelli gerarchici delle informazioni da rendere persi-
stenti: session, process instance, work item.

2. Possibilit` di salvare lo stato dei tre livelli sotto forma di blob binario
a
all’interno del DB.
1
http://www.jboss.org

4.1 Ambiente e configurazione 22

3. Salvataggio dello stato effettuato nei safe state: quando un’istanza di
processo ` in esecuzione dopo il suo inizio oppure dopo la sua ripartenza
e
da uno stato d’attesa, il motore procede finch` non ` pi` possibile
e e u
eseguire ulteriori azioni. A quel punto, ha raggiunto il successivo safe
state, e lo stato del processo viene salvato nuovamente2 . I safe state
corrispondono quindi agli stati d’attesa.

4. Esistenza di un History Log, in grado di memorizzare informazioni
riguardo all’esecuzione di un processo. Sebbene pensati per esigenze
di controllo e debug, possono consentire una ricostruzione della vita
(parziale) del processo. In altre parole, costituiscono una forma di
”fotografia” logica dell’istanza del processo.

Si sono scaricati i sorgenti del motore jBPM, che sono importabili come
progetti Maven3 sulla piattaforma di sviluppo NetBeans4 dal servizio di re-
positoring GitHub5 . All’interno dei sorgenti sono presenti degli esempi di
processi BPMN. Il motore jBPM ` stato configurato affinch` utilizzasse il
e e
DBMS H2 in modalit` TCP, con salvataggio delle informazioni su file sy-
a
stem. Questa modalit` di funzionamento consente di confrontare esecuzioni
a
completate in momenti diversi. Si ` inoltre scelto di sviluppare un nuovo pro-
e
getto NetBeans, compilato con Ant, anzich` utilizzare Maven. Le operazioni
e
per creare e configurare il nuovo progetto sono riassumibili in questi punti:

1. Creazione a partire da un esempio di una classe dotata di metodo main
e sessione persistente.

2. Configurazione Hibernate (una libreria che implementa JPA).
2
http://docs.jboss.org/jbpm/v5.1/userguide/ch07.html
3
http://maven.apache.org
4
http://netbeans.org
5
https://github.com

4.1 Ambiente e configurazione 23

3. Import librerie necessarie al funzionamento, con quelle riguardanti jB-
PM e Drools6 leggermente modificate e compilate a partire dai progetti
Maven.

4. Configurazione di uno Human Task service a partire da un sorgente di
esempio che ha richiesto modifiche non minime.

In particolare l’ultimo punto si ` reso necessario dopo aver appreso che il
e
servizio ` stato modificato nel passaggio da una versione all’altra. Si ` quindi
e e
dovuto provvedere a trovare il server in grado di accoppiarsi con gli esempi
designati. Infatti il sistema di comunicazione Client Server utilizzato nella
demo era di tipo MINA7 , mentre quello richiesto dagli esempi open source `
e
di tipo HornetQ8 .

6
Drools ` una piattaforma di integrazione per business logic in grado di supportare
e
regole, workflow e gestione d’eventi http://www.jboss.org/drools
7
http://mina.apache.org
8
www.jboss.org/hornetq

4.2 Analisi 24

4.2 Analisi
Una volta reso funzionante e conﬁgurato il motore si ` proceduto con un’a-
e
nalisi del funzionamento e della struttura interna. Utilizzando un esempio
che simula l’evolversi di un business process in pi` fasi, eseguite da utenti
u
diversi, si ` provveduto prima a veriﬁcare il salvataggio delle informazioni
e
sul database, poi al ripristino a partire da un punto intermedio del proces-
so. Contestualmente si ` proceduto ad un analisi della struttura con cui `
e e
stato progettato e programmato il modulo di persistenza. Questa analisi ha
consentito di individuare delle caratteristiche interne al modulo e delle ca-
ratteristiche esterne. Infatti alcune scelte progettuali hanno un impatto su
come il modulo si interfaccia con il resto del motore jBPM, piuttosto che su
come funziona o sulle prestazioni.
Il modulo funziona utilizzando tre oggetti (SessionInfo, ProcessInstanceInfo,
WorkItemInfo) che contengono i tag JPA per poter essere salvati sul database
relazionale (Fig. 4.1).

4.2 Analisi 25

Marshalling SessionInfo
Session
0100101101
0001000001 JPA
11....

Marshalling ProcessInstanceInfo
ProcessInstance
0100101101
0100001101 JPA
0101 …

Marshalling
WorkItemInfo
WorkItem
010011010
110110011 JPA
1101...

jBPM Engine

Figura 4.1: Persistenza su jBPM

Il rapporto che intercorre tra queste tre entit` ` di tipo gerarchico: si parte
ae
infatti dalla sessione, che descrive l’ambiente di esecuzione, poi si scende al
processo, che ` la rappresentazione del workﬂow, inﬁne si arriva al work item,
e
che ` un’attivit`. Questi oggetti non hanno nessun tipo di ruolo funzionale
e a
all’interno del motore, hanno solo la capacit`, nel momento precedente al
a
salvataggio, di copiare al loro interno una parte dello stato della sessione
istanziata nel motore, sotto forma di blob binario. Successivamente il loro

4.2 Analisi 26

contenuto viene salvato sul database. Nell’operazione opposta di ripristino,
a partire dalle entry presenti su database si ricostruiscono questi oggetti e
infine l’intera sessione. Nello specifico, utilizzando le annotations JPA in
corrispondenza dei alcuni metodi all’interno del sorgente Java dell’engine, si
forza l’esecuzione di questi metodi che si occupano di generare i blob binari
(uno per oggetto) a partire dallo stato del motore. Le annotazioni utilizzate
sono “@PrePersist“ e “@PreUpdate“. L’esecuzione ` immediatamente ante-
e
cedente all’operazione di store sul database.
Possiamo dividere la struttura interna del modulo persistence in due parti:
la prima si occupa di fornire una sessione con la possibilit` di usare il servizio
a
di persistence, la seconda supporta la prima tramite un servizio di serializza-
zione che genera il blob binario. Al fine di comprendere la struttura interna
del progetto ` stato necessario familiarizzare con alcuni pattern di program-
e
mazione Java, che ricorrevano nella struttura del codice. Infatti poich´ le
e
dimensioni del progetto sono notevoli e gli sviluppatori molti, il codice risul-
ta essere difficile da comprendere. Sono presenti moltissime interfacce che
si frappongono tra un oggetto e l’altro e l’interdipendenza tra un modulo e
l’altro ` alta. Perfino tra Drools e jBPM c’` un alto grado di accoppiamento.
e e
La volont` di sviluppare classi e metodi di bassa complessit` ha portato a
a a
un’esplosione del loro numero. Per orientarsi ` necessario porsi ad un livello
e
di astrazione pi` alto, riconoscendo i pattern di programmazione ricorrenti.
u

4.3 Risultati 27

4.3 Risultati
Queste sono le caratteristiche del motore analizzato, espresse in punti:

1. Il servizio di persistenza ha un comportamento trasparente rispetto
al motore, riesce quindi a non aumentarne la complessit` realizzativa.
a
Richiede per` una conoscenza approfondita del motore per essere imple-
o
mentato. Tutti gli oggetti che contengono informazioni utili a definire
lo stato del motore devono essere in grado di fornire la serializzazione
dei dati contenuti.

2. Il salvataggio effettuato nei safe state ` limitato. Infatti nell’ipotesi di
e
eseguire un processo privo di punti d’attesa, non si raggiungerebbe mai
uno di questi stati.

3. La serializzazione degli oggetti ` effettuata con i Protocol Buffers” 9 ,
e
con l’obiettivo di migliorare le prestazioni.

4. La granularit` della persistence non ` configurabile.
a e

L’analisi effettuata ha quindi portato a una buona conoscenza dello strumen-
to e ad una comprensione delle sue caratteristiche tecniche e del suo contesto
di funzionamento. Partendo da questa analisi ` possibile immaginare quali
e
feature cercare di conservare e quali invece cambiare. Il meccanismo che re-
gola in che punti effettuare il salvataggio merita un’ulteriore considerazione,
perch` risulta essere molto diverso da quello auspicato nella stesura dei nostri
e
obiettivi. Infatti l’obiettivo che ci poniamo ` quello di poter salvaguardare
e
i risultati di tutte le azioni del workflow, che sono prevalentemente (se non
interamente nel nostro caso) da attribuire al risultato di un’elaborazione.
Vincolare il salvataggio ad uno stato d’attesa, non avrebbe senso nel nostro
ambito.

9
http://code.google.com/p/protobuf/

Capitolo 5

Progettazione modulo di
persistenza

5.1 Interfaccia
Gli obiettivi della deﬁnizione dell’interfaccia sono quelli di consentire l’utiliz-
zo della persistenza garantendo la robustezza dell’engine e la facilit` d’uso.
a
Le funzioni necessarie, da implementare e rendere disponibili all’utente sono
le seguenti:

1. Pause - Resume

2. Save - Load

I metodi del punto 1 forniscono la persistenza, mentre i metodi del punto 2
garantiscono l’accesso alla parte di persistenza che consente di sospendere e
poi riprendere l’esecuzione dell’engine. Si ` scelto di rendere visibili queste
e
funzioni perch´ si ritiene che possano essere utili all’utente ﬁnale. Fin dal-
e
le prime fasi della progettazione della persistenza si ` infatti manifestata la
e
chiara separazione tra la fase di sospensione e quella di salvataggio dell’en-
gine e a partire da questa considerazione si ` scelto di rendere disponibile
e

5.1 Interfaccia 29

all’utilizzatore questa funzionalit` intermedia. Una volta stabiliti gli elemen-
a
ti del sottoinsieme di funzioni da implementare necessariamente, si ` deciso
e
di implementare una interfaccia pi` ampia, in grado di fornire accesso anche
u
ad altre funzionalit` gi` presenti nell’engine. Le operazioni aggiuntive che
a a
sono state definite sono le seguenti:

1. Start - Shutdown

2. Forced Shutdown

Il metodo di shutdown inserito nel punto 1 differisce da quello 2 perch´ il
e
primo attende il termine dell’esecuzione prima di spegnere l’engine, men-
tre il secondo esegue uno spegnimento forzato. In questo modo attraverso
un’unica interfaccia ` possibile pilotare tutte le fasi di esecuzione di un pro-
e
cesso da parte dell’engine. Non ` stato ad oggi definito un metodo per la
e
creazione dell’engine e per specificare i parametri di configurazione della per-
sistenza, poich´ il motore ` ancora in una fase di sviluppo sperimentale. Sar`
e e a
necessario definire una struttura in grado di inizializzare il motore ad esem-
pio con il riferimento al servizio di log, piuttosto che il percorso dell’XML
contenete la descrizione del processo. Con il medesimo metodo verr` configu-
a
rata la persistenza, al fine di renderne la configurazione omogenea col resto
dell’engine.

5.2 Progettazione classi e metodi 30

5.2 Progettazione classi e metodi
In fase di progettazione si ` deciso da subito di dividere le problematiche e
e
le relative soluzioni della parte di arresto e ripartenza dell’engine, da quelle
riguardanti il salvataggio e il ripristino. Per essere coerente con gli obiettivi
selezionati per` lo stato di pausa dell’engine deve essere valido (definito nel
o
paragrafo 1.1) e questo tipo di stato deve essere raggiunto ad ogni evolu-
zione dello stato del workflow, ovvero ogni volta che nell’esecuzione ` stata
e
eseguita l’operazione prevista da un elemento del processo. Tutti i metodi
che concorrono alla realizzazione dell’interfaccia definita sopra devono essere
bloccanti. In questo modo, il chiamante ha la garanzia che, quando la fun-
zione chiamata gli restituisce il controllo del flusso d’esecuzione, l’operazione
richiesta ` terminata.
e
Le scelte da effettuare per quanto concerne il primo sotto-obiettivo riguarda-
no l’ordine con cui arrestare i thread e la definizione di come fare per fermarli.
L’ordine di spegnimento e ripristino scelto ` mostrato di seguito:
e

1. Work manager thread

2. Workflow event queue thread

La logica alla base di questa scelta ` quella di sospendere prima l’afflusso
e
di informazioni al motore, e solo successivamente il motore. I due thread
devono venir fermati quando sono in attesa di un elemento da prelevare dalle
code da cui attingono. La possibilit` di terminarli in un altro punto, ovvero
a
mentre processano un elemento prelevato, ` da scartare perch´ porterebbe
e e
a uno stato non valido. Si attender` quindi che i thread siano in attesa e
a
successivamente si proceder` con lo spegnimento. Questa attesa ` ritenuta
a e
accettabile, poich` i task che costituiscono le computazioni pi` dispendiose e
e u
lunghe vengono eseguiti come work item, e quindi non bisogna attenderne il
completamento (il work job engine infatti non viene mai arrestato). Le due
classi che controllano i thread devono esportare un metodo che ne consen-
tano la sospensione e il ripristino. La classe che implementer` l’interfaccia
a


“pausable engine“ dovr` quindi avere accesso alle due classi in questione.
a
Per quanto riguarda invece il salvataggio dello stato, ` semplicemente ne-
e
cessario serializzare lo stato del processo e gli eventi presenti nella workﬂow
event queue (Fig 5.1). Poich´ gli eventi nella coda riferiscono alla process
e
instance i due oggetti vanno salvati insieme. La creazione di una classe con
il ruolo di wrapper risulta essere la soluzione pi` semplice per farlo.
u

Engine State

WorkflowEventQueue
E E E E E

ProcessInstance

Figura 5.1: Oggetti contenenti lo stato dell’engine

Il problema successivo ` l’operazione di ripristino che richiede di ripristinare i
e
riferimenti necessari all’engine per funzionare. La scelta fatta per raggiunge-
re questo obiettivo ` stata quella di fare in modo che fosse la process instance
e
a ricollegarsi ai servizi che necessitano di conoscerla (o di conoscere qualche
suo elemento).
Il primo riferimento da ricostruire ` quello della factory delle process instan-
e
ce, in modo che sia aggiornato e porti alla nuova istanza del processo. La
factory si occupa della creazione delle process instace, ma soprattutto nel


nostro design consente di ottenere sempre il riferimento corretto a queste
ultime, per mezzo di una ricerca tramite id. Si pu` pensare a quest’ultimo
o
collegamento come il punto d’accesso dai livelli gerarchicamente superiori alla
process instance. La soluzione ` eﬃcace a patto che tutti i servizi utilizzino
e
la factory: la restrizione non ` per` di grande impatto. Anche per gli oggetti
e o
in attesa del termine dell’esecuzione del processo (listener) si ` pensato a una
e
soluzione simile. Anzich´ porsi direttamente in ascolto della process instance
e
lo fanno comunicandolo alla factory, che fa da intermediario.
I riferimenti pi` complessi da ricostruire sono quelli del work manager, che
u
consentono di ricevere i risultati delle action dalla work job queue: sono riferi-
menti al corrispettivo nodo della process instance, e questo li rende complessi
da gestire. Si tratta di un caso particolare e limitato al work manager, e la
soluzione adottata prevede che la process instance, esaminandosi rilevi quali
nodi sono in esecuzione presso il work manager. Infatti esiste una struttura
dati che ha proprio il ruolo di indicare quali nodi sono in esecuzione. Il work
manager deve solo essere predisposto all’aggiornamento dei riferimenti.
Per fare in modo che la nuova istanza si possa annunciare deve possedere
dei riferimenti agli oggetti da contattare. Tutti questi riferimenti vengono
acquisiti per mezzo di un unico riferimento alla knowledge session, che le
viene fornito subito dopo la creazione.
In generale, tutti i servizi che verranno aggiunti nel tempo, devono riferire
alla process instance tramite id. Il work manager costituisce il caso parti-
colare pi` complesso da gestire ed ha richiesto una soluzione pi` complessa.
u u
Risolvendo il suo problema si ritiene di aver individuato una metodologia suf-
ﬁcientemente potente per risolvere anche gli altri casi che si presenteranno
in futuro.

Capitolo 6

Implementazione

6.1 Ambiente e integrazione
Al fine di procedere con l’implementazione delle funzionalit` progettate sul-
a
l’engine ESTECO si ` dovuto creare un ambiente di sviluppo adatto. L’engine
e
si appoggia su diversi moduli che sono necessari per il suo funzionamento.
Tutti questi moduli vengono compilati utilizzando uno script Ant. Si ` scelto
e
di non implementare un modulo distinto per la persistenza ma di estendere
quello contenente il core dell’engine. La scelta ` giustificata dalla necessit`
e a
per le classi che implementano la persistenza di conoscere gran parte dell’en-
gine. I due moduli sarebbero quindi stati fortemente accoppiati, rendendo
quasi nulli i benefici derivanti dall’avere due moduli separati. La classe che
implementa l’interfaccia definita in progettazione ` diventata un wrapper
e
dell’engine e consente di pilotarlo.

6.2 Pausa e ripartenza 34

6.2 Pausa e ripartenza
Per arrestare i thread in modo ordinato si ` elaborato un modello di codice
e
per controllarne il comportamento, che con modifiche minime si adatta sia
al work manager che alla workflow event queue:
1 public void run () {
2 isAlive = true ;
3 while ( isAlive ) {
4 Message message = null ;
5 message = queue . receive ( Sender , TIMEOUT ) ;
6 if ( message != null ) {
7 handleMessage ( message ) ;
8 }
9 }

La struttura dell’engine prevedeva che i thread effettuassero un’attesa bloc-
cante sulla coda da cui consumavano gli elementi. Si ` scelto di aggiungere
e
all’attesa bloccante un timeout, che consente di sbloccare il thread, facendo
in modo che raggiunga il punto in cui verifica se proseguire o arrestarsi. Nel
caso invece in cui il thread sia impegnato nella fase di gestione del messaggio
ricevuto ` necessario attedere che questa operazione sia terminata: questa
e
scelta ` necessaria, perch´ ` l’unica che ci consente di raggiungere con cer-
e ee
tezza uno stato corretto. La seconda situazione non consente di porre un
limite superiore al tempo potenzialmente necessario per lo spegnimento. Le
operazioni di gestione di tutti e due i thread sono per` relativamente rapide.
o
Al momento non ` possibile fornire una quantificazione precisa, ma questa
e
caratteristica deriva delle specifiche di progettazione dell’engine.

6.3 Salvataggio e ripristino 35

6.3 Salvataggio e ripristino
Gli oggetti da salvare sono due: il primo ` la process instance, mentre il
e
secondo ` la workflow event queue. La prima scelta ha riguardato la me-
e
todologia da utilizzare per la serializzazione del contenuto informativo delle
classi in questione. Si ` deciso di utilizzare la serializzazione standard offerta
e
da Java ed implementare l’interfaccia serializable: l’alternativa era data dal-
l’utilizzo dell’interfaccia externalizable. La scelta ha delle implicazioni: con
serializable si semplificano i costi di sviluppo,di manutenzione ed evoluzione,
ma si limita le possibili modifiche alla struttura della classe. Infatti nell’i-
potesi di voler cambiare la definizione della classe serializzata, i dati salvati
difficilmente risulterebbero fruibili. Si ` per` considerato che il ciclo di vita
e o
dei dati salvati fosse breve, e quindi si sono ritenuti maggiori i benefici deri-
vanti dall’implementazione di serializable.
Si ` successivamente proceduto al salvataggio dei due oggetti. Si ` fatto ri-
e e
corso ad un oggetto wrapper che contenesse sia la workflow event queue che
la process instance. In questo modo i due oggetti vengono serializzati insieme
e si ottiene sia la garanzia che tutto venga salvato, sia che i riferimenti siano
corretti e non ci siano duplicati. La possibilit` di procedere con un salvatag-
a
gio separato era un alternativa considerata, ma dava luogo a dei problemi
poich´ comporta situazioni diverse a seconda del contenuto della workflow
e
event queue: a seconda che questa contenga o no degli eventi riguardanti la
process instance, cambia la struttura dei dati da salvare. Infatti se la coda `
e
vuota ` necessario salvare solo la process instance, mentre se contiene degli
e
eventi, saranno questi, con i loro riferimenti a scatenare il salvataggio della
process instance, rendendone superfluo e addirittura nocivo il salvataggio se-
parato. Infatti in fase di ripristino questa duplicazione avrebbe implicato la
presenza di due diverse istanze della stessa process instance.
Si ` inoltre deciso di salvare il blob binario cos` ottenuto su file system: non si
e ı
sono prese in considerazioni soluzioni diverse (ad es. un database ad oggetti
o un database relazionale) poich´ non si ritiene questa scelta come critica
e


per la buona riuscita del progetto. Al termine dell’operazione di salvataggio
` necessario procedere con l’eliminazione dei riferimenti all’oggetto appena
e
salvato. Questo consente che venga raccolto dal garbage collector e che non
si creino duplicati in caso di ripristino. Per raggiungere questo fine la process
instance ` stata dotata di un metodo che le consente di svincolarsi dal re-
e
sto del motore. Per la workflow event queue risulta pi` semplice, perch´ c’`
u e e
un solo riferimento da eliminare. Al termine dell’operazione di salvataggio,
l’engine avr` i suoi thread non attivi e sar` svuotato di tutto il contenuto
a a
informativo dinamico.
Per procedere alla ricostruzione della process instance e della workflow event
queue ` sufficiente essere in possesso dei class loader necessari a ripristinare
e
gli oggetti Java a partire dalla loro serializzazione. Una volta ricreati gli og-
getti, ` necessario tornare ad accoppiarli con il resto dell’engine. Per mezzo
e
del riferimento alla knowledge session la process instance ` in grado di rian-
e
nunciarsi alla sua factory e di fornire i riferimenti ai suoi nodi in esecuzione
al work manager. Di seguito si riporta la porzione di codice (lievemente sem-
plificata) che mostra come la process instance analizza il suo stato, per capire
che riferimenti deve trasmettere al workmanager. Si pu` inoltre notare che
o
l’unico punto di aggancio necessario ` la knowledge session (nel codice riferita
e
tramite una delle interfacce che implementa, internal knowledge runtime).
1 public void reconnect ( I n t e r n a l K n o w l e d g e R u n t i m e kruntime ) {
2 s e t K n o w l e d g e R u n t i m e ( kruntime ) ;
3 kruntime . g e t P r o c e s s I n s t a n c e M a n a g e r () . i n t e r n a l A d d P r o c e s s I n s t a n c e ( this ) ;
4 Collection < NodeInstance > o u t e r N o d e N o d e I n s t a n c e s = new
ArrayList < NodeInstance >() ;
5 Collection < TaskNodeInstance > t a s k N o d e I n s t a n c e s = new
ArrayList < TaskNodeInstance >() ;
6 Iterator < NodeInstance > i = nodeInstances . iterator () ;
7 while ( i . hasNext () ) {
8 NodeInstance n = i . next () ;
9 if ( n instanceof O u t e r A c t i v i t y N o d e I n s t a n c e )
10 o u t e r N o d e N o d e I n s t a n c e s . addAll ((( O u t e r A c t i v i t y N o d e I n s t a n c e ) n )
. g e t N o d e I n s t a n c e s () ) ;}
11 i = o u t e r N o d e N o d e I n s t a n c e s . iterator () ;
12 while ( i . hasNext () ) {


13 NodeInstance n = i . next () ;
14 if ( n instanceof T a s k N o de I n s t a n c e )
15 t a s k N o d e I n s t a n c e s . add (( Ta s kN o d e I n s t a n c e ) n ) ;}
16 Iterator < TaskNodeInstance > it = t a s k N o d e I n s t a n c e s . iterator () ;
17 while ( it . hasNext () ) {
18 T a s k N o d e I n s t a n c e current = it . next () ;
19 (( this . g e t K n o w l e d g e R u n t i m e () ) . getWor kManager () )
. a d d E n g i n e E v e n t L i s t e n e r ( current ) ;
20 (( this . g e t K n o w l e d g e R u n t i m e () ) . getWor kManager () )
. re freshWor kMap ( current . getWorkItem () ) ;}
21 }

La ricerca del nodo da inserire nel work manager viene effettuata in modo
progressivo: si itera all’interno del gruppo di nodi in esecuzione, in cerca
di un nodo che contenga un’esecuzione esterna al motore, successivamente
tra questi si cerca un nodo di tipo task (gli unici con esecuzione esterna al
momento). Successivamente i nodi cos` trovati vengono agganciati al work
ı
manager, in modo che siano in grado di ricevere il risultato della loro esecuzio-
ne. La workflow event queue invece deve solo essere nota al suo contenitore,
al quale tutti gli altri oggetti fanno riferimento. Al termine dell’operazione il
contenuto del motore ` esattamente quello precedente al salvataggio. Questo
e
serve a garantire che metodologicamente non si incorra in un errore che possa
inficiare la corretta evoluzione del workflow.

Capitolo 7

Conclusioni

La valutazione di quanto svolto, in relazione agli obiettivi posti ad inizio
lavoro, ` parziale poich´ per poterne formulare una completa sarebbe neces-
e e
sario evolvere ulteriormente il sistema e anche l’engine; si ` per` ottenuto il
e o
funzionamento di quanto posto tra gli obbiettivi. Infatti l’engine ` in grado
e
di salvare il suo stato ad ogni evoluzione dello stato d’esecuzione del work-
flow e successivamente di ricaricarlo, riprendendo l’esecuzione. Nel corso del
lavoro svolto si ` per` individuata la necessit` di porsi degli obiettivi pi` am-
e o a u
biziosi, volendo ottenere un risultato utilizzabile in ambito professionale. Le
principali lacune riguardano le incognite sulla possibilit` di supportare tutti
a
i servizi di cui un workflow ha bisogno e le ulteriori difficolt` da affrontare
a
per utilizzare i risultati ottenuti per implementare un sistema di gestione
degli imprevisti. Sicuramente quanto prodotto ` propedeutico al raggiungi-
e
mento di questi obiettivi pi` ambiziosi, ma non si ` al momento in grado di
u e
prevedere l’entit` di lavoro necessaria a completare il percorso intrapreso. Il
a
progetto svolto ` risultato complesso, principalmente perch´ ha richiesto di
e e
comprendere e modificare la struttura dell’engine e di fare altrettanto con
i meccanismi di funzionamento. Le classi da implementare sono state una
decina, ma i metodi modificati o aggiunti sono stati parecchi di pi`, anche in
u
punti logicamente molto lontani dalle parti descritte nella tesi. Al momento

39

ESTECO sta seguendo un programma di sviluppo nel quale il modello di
workflow proprietario viene sostituito dalla notazione standard BPMN. Le
energie degli sviluppatori sono concentrate sia sull’editor di workflow grafico
che sull’engine. I due componenti diventeranno il cuore dei prodotti soft-
ware desktop ed enterprise compatibili con le specifiche BPMN. Lo sviluppo
della componente di persistenza ` cruciale per ESTECO, poich´ fornir` una
e e a
funzionalit` essenziale per un ambiente di esecuzione di qualit` industriale,
a a
come richiesto dai clienti. Il lavoro svolto in questa tesi ha consentito di
comprendere le problematiche associate alla persistenza e contestualmente
ha fornito informazioni riguardanti gli altri approcci attualmente utilizzati
in ambito industriale. Il modulo sviluppato in questa tesi costituir` la base
a
del componente di produzione, che verr` incluso negli ambienti software di
a
ESTECO.

Bibliografia

[1] Cui Lin, Shiyong Lu, Xubo Fei,Artem Chebotko, Darshan Pai,Zhaoqiang
Lai, Farshad Fotouhi,and Jing Hua (2009), A Reference Architecture for
Scientific Workflow Management Systems and the VIEW SOA Solution.

[2] Jia Yu, Rajkumar Buyya (2005), A Taxonomy of Workflow Management
Systems for Grid Computing.

[3] M. Sonntag, D. Karastoyanova, E. Deelman, “Bridging The Gap Between
Business And Scientific Workflows“.

[4] Heiko Schuldt,Gustavo Alonso,Catriel Beeri,Hans-Jorg Schek (2002), -
Atomicity and Isolation for Transactional Processes.

[5] Yolanda Gil1, Ewa Deelman, Mark Ellisman, Thomas Fahringer, Geoffrey
Fox, Dennis Gannon, Carole Goble, Miron Livny, Luc Moreau, Jim Myers
(2002), Examining the Challenges of Scientific Workflows.

[6] Bertram Lud, Ilkay Altintas, Shawn Bowers, Julian Cummings, Terence
Critchlow, Ewa Deelman, David De Roure, Juliana Freire, Carole Goble,
Matthew Jones, Scott Klasky, Timothy McPhillips, Norbert Podhorsz-
ki, Claudio Silva, Ian Taylor, Mladen Vouk (2010), Scientific Process
Automation and Workflow Management, Chapter 13.

[7] Giuseppe Chechile (2012), Progetto e realizzazione di un sistema per la
gestione ed il monitoraggio di risorse virtuali in ambiente cloud

BIBLIOGRAFIA 41

[8] OMG (2012), Business Process Model and Notation specification
http://www.omg.org/spec/BPMN/2.0

[9] Marco Cella (2012), Progetto e realizzazione di motori BPMN 2.0
estendibili per workflow scientifici e loro valutazione sperimentale

[10] Thomas Weigold (2010), A generic framework for process executiom and
secure multi-party transaction authorization

[11] OMG official site
http://www.omg.org

[12] BPMN official site
http://www.bpmn.org

[13] Bruce Eckel, Thinking in Patterns with Java

[14] Joshua Bloch (2008) Effective JavaTM , Second Edition

Un sistema di persistenza per motori di workflow business-oriented BPMN

Recommended

Recommended

More Related Content

Similar to Un sistema di persistenza per motori di workflow business-oriented BPMN

Similar to Un sistema di persistenza per motori di workflow business-oriented BPMN (20)

Un sistema di persistenza per motori di workflow business-oriented BPMN