Embed Size (px)
Citation preview
Universita degli Studi di Trieste
Dipartimento di Ingegneria e ArchitetturaCorso di Laurea in Ingegneria Informatica
Tesi di Laurea in Programmazione
Un sistema di persistenzaper motori di workflow
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 e orchestrata da appositi engine. Lo
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 e stata sviluppata questa
tesi. Nella tesi si e progettato e realizzato un modulo software per
estendere le funzionalita dell’engine attualmente in sviluppo presso
l’azienda, in particolare per permettere la sospensione dell’esecu-
zione e il successivo ripristino di workflow scientifici.
Il primo capitolo indichera quali sono gli obiettivi del lavoro svolto e quali
sono le particolarita del problema da affrontare. Ai workflow scientifici e
dedicata la prima parte del secondo capitolo. Si indaghera le caratteristiche
di questo mondo e successivamente si cerchera di comprendere in che mo-
do queste peculiarita influenzino i requisiti di un engine e della persistenza.
Il prosieguo del secondo capitolo illustrera le caratteristiche dello standard
“Business Process Modeling Notation”.
II
Il terzo capitolo, descrivera la struttura e il funzionamento del motore ESTE-
CO, esteso in questa tesi con le funzionalita di persistenza. Successivamente
si spieghera qual e lo stato dell’arte nel campo dei motori BPMN in termi-
ni di persistence, e questo verra fatto tramite un’analisi del motore jBPM
prodotto dalla JBoss Community1. In azienda il motore in questione era gia
stato studiato in dettaglio perche ritenuto il migliore in considerazione delle
necessita aziendali. Si contestualizzeranno inoltre le caratteristiche di questo
software, illustrando le motivazioni alla base delle scelte tecniche.
Successivamente si procedera progettando un modulo in grado di soddisfa-
re i requisiti individuati, motivando le scelte progettuali effettuate; conte-
stualmente si definira anche un’interfaccia d’uso. Si concludera con l’im-
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 criticita 1
1.1 Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Criticita . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
Bibliografia 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 criticita
1.1 Obiettivi
Lo scopo del lavoro svolto e quello di creare un’implementazione software
in grado di estendere le funzionalita di un engine BPMN1, consentendo di
salvare il suo stato e ripristinarlo in seguito. Poiche il prodotto finale e stret-
tamente connesso al motore, contestualmente al lavoro di implementazione
e necessario individuare delle metodologie che possano essere riutilizzate, sia
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 piu approfondita verra fatta in seguito, per adesso basti sapere che si
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. Scalabilita [5]
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
necessita di scalabilita.
Gli scopi della nuova funzionalita sono molteplici: il piu banale e quello di
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 puo pensare anche alla
persistenza come mezzo per aumentare la solidita dell’engine; costituisce in-
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 e quella di ripristinare
lo stato dell’engine precedente al fallimento, evitando di dover ricominciare
l’esecuzione dall’inizio.
Al fine di rendere possibile un utilizzo quanto piu ampio delle funzionalita
create, e necessario che i vincoli d’uso e funzionamento siano minimi. Ope-
rativamente questa necessita si traduce nella possibilita di salvare lo stato
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 verra chiamato valido.
Per quanto riguarda le prestazioni del salvataggio, e importante scegliere qua-
li dati salvare, al fine di ottenere tutte le informazioni necessarie, senza pero
introdurre ridondanze. Un ulteriore obiettivo e costituito dalla volonta di
aumentare il meno possibile la complessita interna dell’engine, implementan-
do inoltre soluzioni che non precludano eventuali evoluzioni a cui il motore
potrebbe essere sottoposto.
Anche la complessita d’utilizzo dell’engine deve essere quanto piu contenuta;
a tal fine ci si prefigge l’obiettivo di mettere a disposizione dell’utente un’in-
1.2 Criticita 3
terfaccia che consenta l’utilizzo del motore dotato di persistenza nascondendo
la complessita del funzionamento agli occhi dell’utilizzatore.
1.2 Criticita
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 difficolta di procedere ad un arresto dell’engi-
ne che non solo porti ad uno stato adatto al salvataggio, ma anche che sia il
piu rapido possibile. In presenza di molti thread il soddisfacimento dei due
requisiti non e banale.
Una necessita dei workflow scientifici e quella di essere riproducibili; e quindi
necessario che le modifiche introdotte non alterino in alcun modo il flusso
d’esecuzione.
Le funzionalita di persistenza possono inoltre risultare particolarmente in-
vasive, sia perche potrebbero essere necessarie modifiche alla logica di fun-
zionamento, sia perche richiedono del codice all’interno dell’engine, contri-
buendo ad aumentarne la complessita. Modifiche troppo invasive potrebbero
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 e svolto il lavoro di tesi. Si puo definire
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 piu specifica rispetto a quella di workflow: indica infatti un
flusso con input, output e scopo maggiormente definiti rispetto a quelli del
workflow generico. Un workflow puo contenere piu processi al suo interno.
Durante l’esecuzione di un workflow le informazioni o i processi operativi
sono distribuiti tra gli utenti del sistema, con la finalita di compiere una de-
terminata azione in base a quanto specificato.
Un workflow scientifico e una specializzazione di workflow che descrive un
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 poiche i task in un scientific workflow
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
3. 4.
6.
1. 2.
7.
8. 10.9.
5.
Scientific Workflows
WorkflowsWorkflowsWorkflows
13.12.
11.
16.
15.14.
17.
Figura 2.1: I requisiti dei workflow
1. Human Tasks: un task che deve essere eseguito da un attore umano.
2. Transazionalita.
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. Qualita del servizio.
6. Gestione degli eventi esterni.
7. Concetti di modelli di processo e di istanze di processo.
8. Automazione.
9. Monitoraggio.
10. Scalabilita.
11. Controllo di flusso.
12. Flessibilita.
13. Supporto grid/cluster.
14. Elaborazione tramite pipeline.
15. Riproducibilita.
16. Flusso dei dati esplicito.
17. Gestione di grandi quantita di dati.
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 piu motori di workflow. Un workflow manager (in que-
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
attivita. Tale definizione viene inserita come input del sistema e puo essere
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
puo essere automatica ed indipendente dall’utente che in questo modo occu-
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 necessita ha sviluppato un linguaggio, chiamato Business Process
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 e stato dotato di
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,
1L’OMG e un’associazione internazionale, aperta a tutti e non-profit. Ha come ambitod’interesse il mondo dell’informatica: sviluppa infatti standard di integrazione tra aziendeche interessano numerosi campi tecnologici. http://www.omg.org
2http://www.uml.org
2.2 Business Process Modeling Notation 8
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 riproducibilita e la
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 pero non sono
direttamente legate alla logica d’esecuzione. Di seguito si riporta una breve
panoramica dei principali elementi messi a disposizione dallo standard, divisi
per categorie.
2.2 Business Process Modeling Notation 9
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’attivita, la fine di un’attivita, il
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
2.2 Business Process Modeling Notation 10
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 Business Process Modeling Notation 11
2.2.2 Rappresentazione XML
Ogni workflow e definito da una specifica rappresentazione grafica e da un re-
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 puo parlare della rappre-
sentazione XML come unico elemento di definizione del processo da eseguire.
Di seguito riportiamo un esempio di rappresentazione XML per un processo.
L’esempio e tratto da un documento ufficiale dell’OMG [8] e tratta il pro-
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 provvedera
a revisionare il tutto.
2.2 Business Process Modeling Notation 12
Figura 2.5: Esempio di processo BPMN
1 <?xml version="1.0" encoding="UTF -8"?>
2 <definitions id="Definition"
3 targetNamespace="http://www.example.org/UserTaskExample"
4 typeLanguage="http: //www.w3.org /2001/ XMLSchema"
5 expressionLanguage="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/UserTaskExample">
9 <resource id="regionalManager" name="Regional Manager">
10 <resourceParameter id="buyerName" isRequired="true" name="Buyer Name"
type="xsd:string"/>
11 <resourceParameter id="region" isRequired="false" name="Region"
type="xsd:string"/>
12 </resource >
13 <resource id="departmentalReviewer" name="Departmental Reviewer">
14 <resourceParameter id="buyerName" isRequired="true" name="Buyer Name"
type="xsd:string"/>
15 </resource >
16 <collaboration id="BuyerCollaboration" name="Buyer Collaboration">
17 <participant id="BuyerParticipant" 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 >QuotationHandling </flowNodeRef >
25 <flowNodeRef >ApproveOrder </flowNodeRef >
26 <flowNodeRef >OrderApprovedDecision </flowNodeRef >
27 <flowNodeRef >TerminateProcess </flowNodeRef >
28 <flowNodeRef >OrderAndShipment </flowNodeRef >
29 <flowNodeRef >OrderHandling </flowNodeRef >
2.2 Business Process Modeling Notation 13
30 <flowNodeRef >ShipmentHandling </flowNodeRef >
31 <flowNodeRef >OrderAndShipmentMerge </flowNodeRef >
32 <flowNodeRef >ReviewOrder </flowNodeRef >
33 <flowNodeRef >EndProcess </flowNodeRef >
34 </lane>
35 </laneSet >
36 <startEvent id="StartProcess"/>
37 <sequenceFlow sourceRef="StartProcess" targetRef="QuotationHandling"/>
38 <task id="QuotationHandling" name="Quotation Handling"/>
39 <sequenceFlow sourceRef="QuotationHandling" targetRef="ApproveOrder"/>
40 <userTask id="ApproveOrder" name="ApproveOrder">
41 <potentialOwner >
42 <resourceRef >tns:regionalManager </resourceRef >
43 <resourceParameterBinding parameterRef="tns:buyerName">
44 <formalExpression >getDataInput(’order’)/address/name
</formalExpression >
45 </resourceParameterBinding >
46 <resourceParameterBinding parameterRef="tns:region">
47 <formalExpression >getDataInput(’order’)/address/country
</formalExpression >
48 </resourceParameterBinding >
49 </potentialOwner >
50 </userTask >
51 <sequenceFlow sourceRef="ApproveOrder" targetRef="OrderApprovedDecision"/>
52 <exclusiveGateway id="OrderApprovedDecision"
gatewayDirection="Diverging"/>
53 <sequenceFlow sourceRef="OrderApprovedDecision"
targetRef="OrderAndShipment">
54 <conditionExpression >Was the Order Approved?</conditionExpression >
55 </sequenceFlow >
56 <sequenceFlow sourceRef="OrderApprovedDecision"
targetRef="TerminateProcess">
57 <conditionExpression >Was the Order NOT Approved?</conditionExpression >
58 </sequenceFlow >
59 <endEvent id="TerminateProcess">
60 <terminateEventDefinition id="TerminateEvent"/>
61 </endEvent >
62 <parallelGateway id="OrderAndShipment" gatewayDirection="Diverging"/>
63 <sequenceFlow sourceRef="OrderAndShipment" targetRef="OrderHandling"/>
64 <sequenceFlow sourceRef="OrderAndShipment" targetRef="ShipmentHandling"/>
65 <task id="OrderHandling" name="Order Handling"/>
66 <task id="ShipmentHandling" name="Shipment Handling"/>
67 <sequenceFlow sourceRef="OrderHandling"
targetRef="OrderAndShipmentMerge"/>
68 <sequenceFlow sourceRef="ShipmentHandling"
targetRef="OrderAndShipmentMerge"/>
2.2 Business Process Modeling Notation 14
69 <parallelGateway id="OrderAndShipmentMerge"
gatewayDirection="Converging"/>
70 <sequenceFlow sourceRef="OrderAndShipmentMerge" targetRef="ReviewOrder"/>
71 <userTask id="ReviewOrder" name="Review Order">
72 <potentialOwner >
73 <resourceRef >tns:departmentalReviewer </resourceRef >
74 <resourceParameterBinding parameterRef="tns:buyerName">
75 <formalExpression >getDataInput(’order’)/address/name</formalExpression >
76 </resourceParameterBinding >
77 </potentialOwner >
78 </userTask >
79 <sequenceFlow sourceRef="ReviewOrder" targetRef="EndProcess"/>
80 <endEvent id="EndProcess"/>
81 </process >
82 </definitions >
Come si puo vedere dal documento XML la definizione che viene data del
processo e divisa in piu parti. Nella prima vengono definite le risorse che
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 vastita dei componenti e delle
possibilita offerte da BPMN rende improponibile trattarli tutti in questo
documento. Si ritiene pero che il seppur limitato sottoinsieme di componenti
introdotto sia in grado di fornire un’indicazione di massima sulle potenzialita
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 e stato sviluppato all’interno dell’azienda ESTECO, ed
era, al momento dell’inizio di questo lavoro, la versione piu aggiornata in pos-
sesso dell’azienda. La struttura e rappresentata in figura 3.1. A partire da un
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 e statico, prende il nome di knowledge base, e rappresenta il corrispettivo
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) e rappresentato come un
albero dove ogni nodo e figlio dei nodi da cui dipende: il nodo di partenza
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
1La coda e una struttura dati gestita con un criterio FIFO.
3.1 Struttura 16
e dai gateway vengono elaborati tramite questa coda. Per le activity invece
e stata adottata una soluzione diversa. In ESTECO si e scelto infatti di
eseguirle all’esterno dell’engine, sia perche potrebbero richiedere risorse non
disponibili all’engine, sia perche con la struttura scelta e possibile distribuire
il carico d’esecuzione. Infatti le activity da eseguire vengono affidate a un
work manager, che si occupa di impacchettarle all’interno di un messaggio
(work message), contenente i dati di input e le specifiche 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 e una normale coda Java,
ma e prevista l’adozione di una coda dotata di transazionalita e persistenza.
3.1 Struttura 17
Workflow Event Queue
Process Instance
Workflow Engine
Runnable
Work Manager
WIMWIM WIM
Work Item Message (WIM)
WIMWIM
Work Job Engine
X=3
Runnable Runnable
Work Message Queue
X=?
Job 1
Job 2
Job 3
Work Job Engine
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 e neces-
sario entrare piu nel dettaglio della struttura di quella parte di engine che
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 e imple-
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 entita dell’engine. Infatti e questo oggetto,
tramite la process runtime, ad offrire tutti i servizi che servono per l’esecu-
zione, tra cui il work manager. La process instance e l’oggetto contenente
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 e l’esecuzione
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
Process Instance
KnowledgeBase
Definizione Statica del Processo
Definizione dinamica del Processo
Knowledge Session
Process Runtime
Servizi
Workflow Event Queue
Work Manager
Workflow Engine
Figura 3.2: Struttura workflow 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 e importante,
soprattutto nell’ottica di sviluppare uno spegnimento ordinato dell’engine.
La spiegazione che seguira fa riferimento sempre alla figura 3.1.
Il primo thread da considerare e associato alla workflow event queue. Svolge
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 necessita
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 e legato al work manager. Anche lui ha un ruolo di consu-
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 e il frutto di un’esecuzione da parte di un work job engine. Il
processo di ricezione di un work message e diviso in due fasi. Nella prima si
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 analizzera il funzionamento e la struttura della parte di
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 funzionalita. Si e fatto uso dei seguenti tool:
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. Possibilita di salvare lo stato dei tre livelli sotto forma di blob binario
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 e in esecuzione dopo il suo inizio oppure dopo la sua ripartenza
da uno stato d’attesa, il motore procede finche non e piu possibile
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 e stato configurato affinche utilizzasse il
DBMS H2 in modalita TCP, con salvataggio delle informazioni su file sy-
stem. Questa modalita di funzionamento consente di confrontare esecuzioni
completate in momenti diversi. Si e inoltre scelto di sviluppare un nuovo pro-
getto NetBeans, compilato con Ant, anziche utilizzare Maven. Le operazioni
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).
2http://docs.jboss.org/jbpm/v5.1/userguide/ch07.html3http://maven.apache.org4http://netbeans.org5https://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 e reso necessario dopo aver appreso che il
servizio e stato modificato nel passaggio da una versione all’altra. Si e quindi
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.
6Drools e una piattaforma di integrazione per business logic in grado di supportareregole, workflow e gestione d’eventi http://www.jboss.org/drools
7http://mina.apache.org8www.jboss.org/hornetq
4.2 Analisi 24
4.2 Analisi
Una volta reso funzionante e configurato il motore si e proceduto con un’a-
nalisi del funzionamento e della struttura interna. Utilizzando un esempio
che simula l’evolversi di un business process in piu fasi, eseguite da utenti
diversi, si e provveduto prima a verificare il salvataggio delle informazioni
sul database, poi al ripristino a partire da un punto intermedio del proces-
so. Contestualmente si e proceduto ad un analisi della struttura con cui 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
WorkItem
ProcessInstance
Session
SessionInfo
JPA0100101101000100000111....
ProcessInstanceInfo
010010110101000011010101 …
WorkItemInfo
0100110101101100111101...
jBPM Engine
JPA
JPA
Marshalling
Marshalling
Marshalling
Figura 4.1: Persistenza su jBPM
Il rapporto che intercorre tra queste tre entita e di tipo gerarchico: si parte
infatti dalla sessione, che descrive l’ambiente di esecuzione, poi si scende al
processo, che e la rappresentazione del workflow, infine si arriva al work item,
che e un’attivita. Questi oggetti non hanno nessun tipo di ruolo funzionale
all’interno del motore, hanno solo la capacita, nel momento precedente al
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 e immediatamente ante-
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 possibilita di usare il servizio
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 e stato necessario familiarizzare con alcuni pattern di program-
mazione Java, che ricorrevano nella struttura del codice. Infatti poiche le
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 e alta. Perfino tra Drools e jBPM c’e un alto grado di accoppiamento.
La volonta di sviluppare classi e metodi di bassa complessita ha portato a
un’esplosione del loro numero. Per orientarsi e necessario porsi ad un livello
di astrazione piu alto, riconoscendo i pattern di programmazione ricorrenti.
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 complessita realizzativa.
Richiede pero una conoscenza approfondita del motore per essere imple-
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 e limitato. Infatti nell’ipotesi di
eseguire un processo privo di punti d’attesa, non si raggiungerebbe mai
uno di questi stati.
3. La serializzazione degli oggetti e effettuata con i Protocol Buffers” 9,
con l’obiettivo di migliorare le prestazioni.
4. La granularita della persistence non e configurabile.
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 e possibile immaginare quali
feature cercare di conservare e quali invece cambiare. Il meccanismo che re-
gola in che punti effettuare il salvataggio merita un’ulteriore considerazione,
perche risulta essere molto diverso da quello auspicato nella stesura dei nostri
obiettivi. Infatti l’obiettivo che ci poniamo e quello di poter salvaguardare
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.
9http://code.google.com/p/protobuf/
Capitolo 5
Progettazione modulo di
persistenza
5.1 Interfaccia
Gli obiettivi della definizione dell’interfaccia sono quelli di consentire l’utiliz-
zo della persistenza garantendo la robustezza dell’engine e la facilita d’uso.
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 e scelto di rendere visibili queste
funzioni perche si ritiene che possano essere utili all’utente finale. Fin dal-
le prime fasi della progettazione della persistenza si e infatti manifestata la
chiara separazione tra la fase di sospensione e quella di salvataggio dell’en-
gine e a partire da questa considerazione si e scelto di rendere disponibile
5.1 Interfaccia 29
all’utilizzatore questa funzionalita intermedia. Una volta stabiliti gli elemen-
ti del sottoinsieme di funzioni da implementare necessariamente, si e deciso
di implementare una interfaccia piu ampia, in grado di fornire accesso anche
ad altre funzionalita gia presenti nell’engine. Le operazioni aggiuntive che
sono state definite sono le seguenti:
1. Start - Shutdown
2. Forced Shutdown
Il metodo di shutdown inserito nel punto 1 differisce da quello 2 perche il
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 e possibile pilotare tutte le fasi di esecuzione di un pro-
cesso da parte dell’engine. Non e stato ad oggi definito un metodo per la
creazione dell’engine e per specificare i parametri di configurazione della per-
sistenza, poiche il motore e ancora in una fase di sviluppo sperimentale. Sara
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 verra configu-
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 e deciso da subito di dividere le problematiche 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 pero lo stato di pausa dell’engine deve essere valido (definito nel
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 e stata
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 e terminata.
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 e mostrato di seguito:
1. Work manager thread
2. Workflow event queue thread
La logica alla base di questa scelta e quella di sospendere prima l’afflusso
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 possibilita di terminarli in un altro punto, ovvero
mentre processano un elemento prelevato, e da scartare perche porterebbe
a uno stato non valido. Si attendera quindi che i thread siano in attesa e
successivamente si procedera con lo spegnimento. Questa attesa e ritenuta
accettabile, poiche i task che costituiscono le computazioni piu dispendiose e
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 implementera l’interfaccia
5.2 Progettazione classi e metodi 31
“pausable engine“ dovra quindi avere accesso alle due classi in questione.
Per quanto riguarda invece il salvataggio dello stato, e semplicemente ne-
cessario serializzare lo stato del processo e gli eventi presenti nella workflow
event queue (Fig 5.1). Poiche gli eventi nella coda riferiscono alla process
instance i due oggetti vanno salvati insieme. La creazione di una classe con
il ruolo di wrapper risulta essere la soluzione piu semplice per farlo.
Engine State
ProcessInstance
WorkflowEventQueue
E E E E E
Figura 5.1: Oggetti contenenti lo stato dell’engine
Il problema successivo e l’operazione di ripristino che richiede di ripristinare i
riferimenti necessari all’engine per funzionare. La scelta fatta per raggiunge-
re questo obiettivo e stata quella di fare in modo che fosse la process instance
a ricollegarsi ai servizi che necessitano di conoscerla (o di conoscere qualche
suo elemento).
Il primo riferimento da ricostruire e quello della factory delle process instan-
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
5.2 Progettazione classi e metodi 32
nostro design consente di ottenere sempre il riferimento corretto a queste
ultime, per mezzo di una ricerca tramite id. Si puo pensare a quest’ultimo
collegamento come il punto d’accesso dai livelli gerarchicamente superiori alla
process instance. La soluzione e efficace a patto che tutti i servizi utilizzino
la factory: la restrizione non e pero di grande impatto. Anche per gli oggetti
in attesa del termine dell’esecuzione del processo (listener) si e pensato a una
soluzione simile. Anziche porsi direttamente in ascolto della process instance
lo fanno comunicandolo alla factory, che fa da intermediario.
I riferimenti piu complessi da ricostruire sono quelli del work manager, che
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 piu complesso da gestire ed ha richiesto una soluzione piu complessa.
Risolvendo il suo problema si ritiene di aver individuato una metodologia suf-
ficientemente 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 funzionalita progettate sul-
l’engine ESTECO si e dovuto creare un ambiente di sviluppo adatto. L’engine
si appoggia su diversi moduli che sono necessari per il suo funzionamento.
Tutti questi moduli vengono compilati utilizzando uno script Ant. Si e scelto
di non implementare un modulo distinto per la persistenza ma di estendere
quello contenente il core dell’engine. La scelta e giustificata dalla necessita
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 e diventata un wrapper
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 e elaborato un modello di codice
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 e scelto di aggiungere
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 e necessario attedere che questa operazione sia terminata: questa
scelta e necessaria, perche e l’unica che ci consente di raggiungere con cer-
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 pero relativamente rapide.
Al momento non e possibile fornire una quantificazione precisa, ma questa
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 e la process instance, mentre il
secondo e la workflow event queue. La prima scelta ha riguardato la me-
todologia da utilizzare per la serializzazione del contenuto informativo delle
classi in questione. Si e deciso di utilizzare la serializzazione standard offerta
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 e pero considerato che il ciclo di vita
dei dati salvati fosse breve, e quindi si sono ritenuti maggiori i benefici deri-
vanti dall’implementazione di serializable.
Si e successivamente proceduto al salvataggio dei due oggetti. Si e fatto ri-
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 possibilita di procedere con un salvatag-
gio separato era un alternativa considerata, ma dava luogo a dei problemi
poiche comporta situazioni diverse a seconda del contenuto della workflow
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 e necessario salvare solo la process instance, mentre se contiene degli
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 e inoltre deciso di salvare il blob binario cosı ottenuto su file system: non si
sono prese in considerazioni soluzioni diverse (ad es. un database ad oggetti
o un database relazionale) poiche non si ritiene questa scelta come critica
6.3 Salvataggio e ripristino 36
per la buona riuscita del progetto. Al termine dell’operazione di salvataggio
e necessario procedere con l’eliminazione dei riferimenti all’oggetto appena
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 e stata dotata di un metodo che le consente di svincolarsi dal re-
sto del motore. Per la workflow event queue risulta piu semplice, perche c’e
un solo riferimento da eliminare. Al termine dell’operazione di salvataggio,
l’engine avra i suoi thread non attivi e sara svuotato di tutto il contenuto
informativo dinamico.
Per procedere alla ricostruzione della process instance e della workflow event
queue e sufficiente essere in possesso dei class loader necessari a ripristinare
gli oggetti Java a partire dalla loro serializzazione. Una volta ricreati gli og-
getti, e necessario tornare ad accoppiarli con il resto dell’engine. Per mezzo
del riferimento alla knowledge session la process instance e in grado di rian-
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 puo inoltre notare che
l’unico punto di aggancio necessario e la knowledge session (nel codice riferita
tramite una delle interfacce che implementa, internal knowledge runtime).
1 public void reconnect(InternalKnowledgeRuntime kruntime){
2 setKnowledgeRuntime(kruntime);
3 kruntime.getProcessInstanceManager ().internalAddProcessInstance(this);
4 Collection <NodeInstance > outerNodeNodeInstances = new
ArrayList <NodeInstance >();
5 Collection <TaskNodeInstance > taskNodeInstances = new
ArrayList <TaskNodeInstance >();
6 Iterator <NodeInstance > i = nodeInstances.iterator ();
7 while (i.hasNext ()) {
8 NodeInstance n = i.next();
9 if (n instanceof OuterActivityNodeInstance)
10 outerNodeNodeInstances.addAll ((( OuterActivityNodeInstance)n)
.getNodeInstances ());}
11 i = outerNodeNodeInstances.iterator ();
12 while (i.hasNext ()) {
6.3 Salvataggio e ripristino 37
13 NodeInstance n = i.next();
14 if (n instanceof TaskNodeInstance)
15 taskNodeInstances.add(( TaskNodeInstance) n);}
16 Iterator <TaskNodeInstance > it= taskNodeInstances.iterator ();
17 while (it.hasNext ()) {
18 TaskNodeInstance current=it.next();
19 ((this.getKnowledgeRuntime ()).getWorkManager ())
.addEngineEventListener(current);
20 ((this.getKnowledgeRuntime ()).getWorkManager ())
.refreshWorkMap(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 e esattamente quello precedente al salvataggio. Questo
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, e parziale poiche per poterne formulare una completa sarebbe neces-
sario evolvere ulteriormente il sistema e anche l’engine; si e pero ottenuto il
funzionamento di quanto posto tra gli obbiettivi. Infatti l’engine e in grado
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 e pero individuata la necessita di porsi degli obiettivi piu am-
biziosi, volendo ottenere un risultato utilizzabile in ambito professionale. Le
principali lacune riguardano le incognite sulla possibilita di supportare tutti
i servizi di cui un workflow ha bisogno e le ulteriori difficolta da affrontare
per utilizzare i risultati ottenuti per implementare un sistema di gestione
degli imprevisti. Sicuramente quanto prodotto e propedeutico al raggiungi-
mento di questi obiettivi piu ambiziosi, ma non si e al momento in grado di
prevedere l’entita di lavoro necessaria a completare il percorso intrapreso. Il
progetto svolto e risultato complesso, principalmente perche ha richiesto di
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 piu, anche in
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 e cruciale per ESTECO, poiche fornira una
funzionalita essenziale per un ambiente di esecuzione di qualita industriale,
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 costituira la base
del componente di produzione, che verra incluso negli ambienti software di
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
