Universit degli Studi di Trieste

Facolt di Scienze Matematiche, Fisiche e Naturali Corso di Laurea Magistrale in Informatica Curriculum Ingegneria Informatica

PROGETTO E REALIZZAZIONE DI MOTORI BPMN 2.0 ESTENSIBILI PER WORKFLOW SCIENTIFICI E LORO VALUTAZIONE SPERIMENTALE

Laureando: Marco CELLA

Relatore: Prof. Ing. Eric MEDVET Correlatore:

Dott. Carlos KAVKA

Anno Accademico 2010/2011

Indice

Introduzione .................................................................................................................. 1 Capitolo 1 - Workflow scientifici .................................................................................... 3 Esempio applicativo .................................................................................................. 3 Ottimizzazione multi obiettivo................................................................................. 4 Esempio di ottimizzazione ..................................................................................... 5 Architettura di riferimento per i SWfMS...................................................................... 8 Capitolo 2 - BPMN 2.0 ................................................................................................ 13 BPMN 2.0 metamodel ............................................................................................. 15 XSD Schema namespace .................................................................................... 16 Workflow definition............................................................................................... 17 Data Object ............................................................................................................. 19 Activity..................................................................................................................... 20 Loop Activity e Multiple Instances Activity ............................................................ 20 Task..................................................................................................................... 21 Sub-Process ........................................................................................................ 22 Capitolo 3 - Estensibilit del modello semantico ......................................................... 23 BPMN 2.0 Extensibility ............................................................................................ 23 Estensione per addizione..................................................................................... 23 Estensione per derivazione .................................................................................. 26 XML Schema Redefine ........................................................................................ 27 Capitolo 4 - JBoss jBPM 5 .......................................................................................... 29 Core Engine ............................................................................................................ 29 Struttura ed istanza del workflow ............................................................................. 30 Modello semantico della specifica BPMN 2.0 .......................................................... 30 Loop Activity ............................................................................................................ 31 Service Task ........................................................................................................... 31 Analisi di una estensione dellelemento Service Task .......................................... 31 Sub-Process............................................................................................................ 33 Analisi della estensione Sub-Process Loop Activity ............................................. 33 Capitolo 5 - Alfresco Activiti ........................................................................................ 35 Core Engine ............................................................................................................ 35 Parser BPMN 2.0 .................................................................................................... 36 i

Modello Semantico della specifica BPMN 2.0.......................................................... 37 Loop Activity ............................................................................................................ 37 Service Task ........................................................................................................... 37 Analisi di una estensione dellelemento Service Task .......................................... 38 Capitolo 6 - Confronto motori BPMN 2.0 ..................................................................... 41 Applicabilit delle estensioni .................................................................................... 41 Confronto delle prestazioni ...................................................................................... 42 Parametri di valutazione ...................................................................................... 42 Algoritmo Welded Beam Design .......................................................................... 43 Modello di Workflow per il problema Welded beam design .................................. 44 Risultati ................................................................................................................ 46 Conclusioni ................................................................................................................. 48 Bibliografia .................................................................................................................. 50

ii

Indice delle figure

Figura 1 - Problema di ottimizzazione: fasi di studio e strumenti ................................... 5 Figura 2 - Sail flying shape morphing box ..................................................................... 6 Figura 3 - Morphing parameters .................................................................................... 6 Figura 4 - Airfoil nomenclature ...................................................................................... 6 Figura 5 - Modello di workflow per il problema di ottimizzazione di esempio ................. 7 Figura 6 - Ciclo di vita di un workflow scientifico ........................................................... 9 Figura 7 - Architettura di riferimento per workflow scientifici ........................................ 11 Figura 8 - Architettura di riferimento per business workflow ........................................ 11 Figura 9 - Rappresentazione grafica workflow di esempio .......................................... 17 Figura 10 - Extension: struttura del documento XML Schema..................................... 24 Figura 11 - JBoss jBPM Core Engine API ................................................................... 29 Figura 12 - Struttura del nodo Sub-Process Loop Activity ........................................... 33 Figura 13 - Struttura logica degli elementi Activity ....................................................... 36 Figura 14 - Parser motore Activiti, diagramma delle classi .......................................... 36 Figura 15 - Schema concettuale della estensione del Service Task ............................ 39 Figura 16 - Welded Beam ........................................................................................... 43 Figura 17 - Modello di workflow per il problema Welded beam design ........................ 45 Figura 18 - Tempo di esecuzione del workflow per il problema Welded beam design . 46 Figura 19 - Tempo di esecuzione del workflow per il problema Welded beam design (secondo test) ............................................................................................................. 47

iii

Introduzione

Il concetto di workflow legato al contesto di automazione dei passi di esecuzione dei processi, per un ampio insieme di problemi, dallambito industriale ai servizi finanziari, dalle telecomunicazioni alla ricerca scientifica. I workflow scientifici sono diventati un paradigma emergente per lo sviluppo di sistemi di calcolo integrati o distribuiti per lautomazione di processi scientifici legati alla risoluzione di problemi scientifici. I workflow scientifici sono intesi come un supporto per gli scienziati, permettono di semplificare lanalisi e la gestione dei dati. Relativamente lambito scientifico i workflow devono supportare ambienti di calcolo complessi, elaborazioni di grandi quantit di dati, sistemi ad elevata affidabilit e lintegrazione di differenti sorgenti dati e servizi esterni anche distribuiti. Le operazioni di creazione, gestione, esecuzione e monitoraggio dei workflow scientifici viene affidata a sistemi di controllo chiamati SWfMS (Scientific Workflow Management System). Lo sviluppo dei sistemi di controllo per workflow scientifici parte dalla formalizzazione delle loro caratteristiche e requisiti, in funzione agli obiettivi della ricerca scientifica; questi sistemi di controllo sono stati recentemente introdotti e si sono sviluppati per lo pi come evoluzione e specializzazione dei sistemi di controllo per business workflow BWfMS (Business Workflow Management System), soprattutto a seguito della introduzione della specifica BPMN 2.0 (Business Process Model and Notation), che ha permesso di formalizzare i componenti del workflow ed il modello semantico di riferimento. Molti componenti, strumenti e costrutti dei business workflow sono adattabili nello sviluppo di sistemi di controllo per workflow scientifici, tuttavia gli obiettivi dei due sistemi sono differenti. In questo contesto si inserisce il problema di estendere il modello semantico della specifica BPMN 2.0 e di sviluppare specifici componenti da inserire nel flusso di esecuzione dei workflow scientifici. Il lavoro di tesi propone una implementazione di due motori di esecuzione per sistemi di controllo per workflow scientifici, sviluppati come evoluzione dei motori di esecuzione per business workflow JBoss jBPM 5 ed Alfresco Activiti.

[1]

Nello svilluppo dei motori di esecuzione per workflow scientifici devono essere valutate le modalit di estensione del modello semantico della specifica BPMN 2.0 e la capacit di inserimento o estensione di specifici elementi per i motori jBPM 5 ed Activiti. I due sistemi di controllo per workflow scientifici saranno quindi confrontati in base alle prestazioni dei motori di esecuzione su specifici parametri di valutazione. Le motivazioni che hanno portato alla selezione dei framework JBoss jBPM 5 ed Alfresco Activiti derivano da scelte aziendali; i parametri di selezione hanno dato maggiore rilevanza ai prodotti sviluppati con linguaggio Java ed ai prodotti con licenza Apache; inoltre, la compatibilit con Alfresco ECM (Enterprise Content Manager), ha ulteriormente consolidato la scelta dei due framework. Questo lavoro di tesi stato svolto presso Esteco S.p.A. AREA Science Park Trieste. Il documento di tesi sviluppato in 6 capitoli; di seguito viene riassunto il contenuto di ciascun capitolo. Capitolo 1: introduce i concetti alla base dei workflow scientifici, inoltre descrive i requisiti ed i principali componenti e strumenti di un modello di riferimento per sistemi di controllo per workflow scientifici. Capitolo 2: richiama alcuni concetti e componenti dello standard BPMN 2.0. Capitolo 3: descrive le possibili estensioni del modello semantico della specifica BPMN 2.0, in base a determinati costrutti della specifica XML Schema. Capitolo 4: esamina le estensioni applicabili ad alcuni elementi della specifica BPMN 2.0 nel framework JBoss jBPM 5. Capitolo 5: esamina le estensioni applicabili ad alcuni elementi della specifica BPMN 2.0 nel framework Alfresco Activiti. Capitolo 6: confronto fra i motori jBPM 5 ed Activiti riguardo lestensibilit di alcuni elementi della specifica BPMN 2.0 e le funzionalit del motore di esecuzione; confronto delle prestazioni dei motori di esecuzione.

[2]

Capitolo 1

Workflow scientifici

I workflow scientifici si stanno affermando come paradigma di sviluppo per sistemi di calcolo nella automazione di processi scientifici, legati alla risoluzione di problemi scientifici. Questi sistemi di calcolo sono spesso distribuiti, devono gestire ed elaborare enormi quantit di dati, quindi fornire i risultati della elaborazione in modo affidabile, attraverso un processo di esecuzione scientificamente riproducibile. Negli ultimi anni sono stati sviluppati diversi sistemi di controllo per workflow scientifici, chiamati SWfMS (Scientific Workflow Management System); questi sistemi di controllo sono necessari nelle operazioni di creazione, gestione, esecuzione e monitoraggio dei workflow scientifici; forniscono inoltre un supporto nella ricerca scientifica per tutti i processi di elaborazione anche solo parzialmente automatizzabili. Due sono le principali strade seguite per lo sviluppo di sistemi di controllo per workflow scientifici: elaborazione di un sistema di controllo ad-hoc a partire dalle caratteristiche del modello e gli obiettivi da perseguire, oppure sviluppare il sistema di controllo a partire da un sistema di controllo esistente, con un processo di sviluppo consolidato ed un modello semantico ben definito. Il modello seguito usualmente prevede lo sviluppo dei sistemi di controllo per workflow scientifici a partire dai sistemi di controllo per business workflow, chiamati BWfMS (Business Workflow Management System); infatti molti dei componenti e costrutti per i due sistemi di controllo sono comuni; inoltre, a seguito della introduzione della specifica BPMN 2.0, lo sviluppo dei sistemi di controllo per business workflow si sta consolidando attorno ad uno standard e ad un modello semantico di riferimento.

Esempio applicativo
Prima di cominciare a discutere con maggiore dettaglio larchitettura dei sistemi di controllo per workflow scientifici, utile comprendere come il concetto di workflow si inserisca nella risoluzione di problemi computazionali in campo scientifico. Sar preso in esame un problema di ottimizzazione multi obiettivo in campo ingegneristico, ed illustrato come il workflow sia inserito nella struttura del problema di ottimizzazione.

[3]

Ottimizzazione multi obiettivo

Per comprendere lesempio che verr proposto in seguito, necessario introdurre i principali concetti associati alla risoluzione di problemi di ottimizzazione multi obiettivo. I problemi di ottimizzazione multi obiettivo sono costituiti da un insieme di funzioni obiettivo da massimizzare e/o minimizzare, ed un insieme di vincoli associati alle variabili decisionali del problema. I metodi di risoluzione computazionale per i problemi di ottimizzazione multi obiettivo spesso presentano funzioni obiettivo in conflitto fra loro. La soluzione di un problema di ottimizzazione multi obiettivo riguarda la determinazione del fronte di Pareto, costituito dalle soluzioni del problema non dominate, cio le soluzioni ammissibili del problema per le quali il miglioramento di una delle funzioni obiettivo porterebbe ad un peggioramento della soluzione per almeno unaltra funzione obiettivo. La soluzione di un problema di ottimizzazione multi obiettivo pu essere ottenuta applicando diversi algoritmi di ottimizzazione, ad esempio algoritmi basati sul gradiente ed algoritmi genetici. Un problema di ottimizzazione multi obiettivo si scompone in diverse fasi di studio, ognuna delle quali viene condotta da specifici strumenti di supporto. Le principali fasi riguardano la pianificazione della ottimizzazione, la simulazione del workflow ed il postprocessing (data mining). In Figura 1 sono schematizzate le fasi di studio di un problema di ottimizzazione e le relazioni fra queste. Lo scheduler uno strumento usato per pianificare e coordinare la fase di ottimizzazione, mediante la definizione dei parametri necessari per la fase di simulazione, condotta dal workflow scientifico; i principali parametri riguardano: definizione delle variabili di input ed output e vincoli sulle variabili, selezione degli obiettivi (funzioni obiettivo), scelta del DoE (Design of Experiments) e dellalgoritmo di ottimizzazione da applicare. Lobiettivo della fase di ottimizzazione la selezione dei migliori design o configurazioni dei parametri in ingresso. Il risultato della fase di ottimizzazione riguarda la determinazione del fronte di Pareto sui risultati ottenuti dalla simulazione del workflow. Il workflow scientifico rappresenta il modello della simulazione ed composto da un flusso dati ed un flusso di esecuzione; il flusso dati definisce linsieme delle variabili di input ed output per ogni nodo di elaborazione, inoltre specifica come i dati sono trasferiti tra i diversi nodi e quali trasformazioni sono applicate ai dati; le variabili di [4]

input necessarie per iniziare lelaborazione del workflow sono i parametri di configurazione (le variabili di input definite dallo scheduler); il flusso di esecuzione invece rappresenta la sequenza dei passi di elaborazione dellintero processo ed illustra le scelte tra vari percorsi alternativi in base allo stato di esecuzione del processo, ai dati applicativi ed in base a regole preassegnate.

Workflow (fase di simulazione)

Parametri di input

Modello di workflow

Metriche di output

Vincoli sui valori di input ed output Scelta degli obiettivi Scelta DOE Scelta algoritmo di ottimizzazione Scheduler (pianificazione della ottimizzazione) Fronte di Pareto

Ottimizzazione multi obiettivo

Post processing (Data mining) Clustering Correlation

Figura 1 - Problema di ottimizzazione: fasi di studio e strumenti

La fase di post processing o data mining permette di comprendere i risultati ottenuti nella fase di ottimizzazione e le motivazioni che hanno portato alla selezione dei diversi design. Le principali tecniche usate sono clustering e correlation analyses.

Esempio di ottimizzazione
Con lesempio proposto in questa sezione si intende introdurre una possibile applicazione reale dei workflow nella ricerca scientifica; non saranno inseriti dettagli riguardo la teoria e gli strumenti usati nella risoluzione dei problemi di ottimizzazione.

[5]

Introduciamo quindi un esempio di problema reale, ripreso dallo studio di una applicazione della fluidodinamica computazionale (CDF) nello sviluppo del design di un modello di vela per imbarcazioni yacht (Clarich & Russo, 2011). In particolare sar analizzato il modello di workflow scientifico associato a questo problema di ottimizzazione che, diversamente dallarticolo di riferimento, sar costruito seguendo il modello semantico della specifica BPMN 2.0. Il problema affronta lo studio della figura deformata della vela dellimbarcazione in condizioni di operativit. Lobiettivo principale nella progettazione della figura della vela riguarda la massimizzazione della forza motrice; inoltre, per fornire sufficiente stabilit trasversale, un secondo obiettivo riguarda la minimizzazione del momento di sbandamento.

Figura 2 - Sail flying shape morphing box

Figura 3 - Morphing parameters

Figura 4 - Airfoil nomenclature

[6]

Le variabili di progettazione sono tutte riferite alla figura della vela. Il problema definito da 10 variabili di progettazione, inclusi (dalla Figura 3) camber (rapporto tra le lunghezze draft e chord) e draft (posizione del massimo spessore della curvatura relativamente la chord line) per tutte e 4 le sezioni della figura (a 0%, 25%, 50% e 75% dellaltezza totale) e twist (angolo di attacco della sezione della vela) per 2 sezioni (al 50% e 75% dellaltezza totale). In Figura 4 sono indicati i principali parametri della sezione della vela. Ogni variabile viene rappresentata nel workflow come un elemento DataObject; per semplificare la rappresentazione, i range di variazione delle variabili sono raggruppati in un unico elemento DataObject. Il workflow in Figura 5 costituito di un flusso dati ed un flusso di esecuzione; il flusso dati, che si sviluppa dallalto verso il basso, contiene un nodo di input per ogni parametro di configurazione (nodi di input del processo) ed un nodo di output per ogni metrica prodotta dal simulatore (nodi di output del processo). In un problema di ottimizzazione normalmente solo un insieme delle metriche prodotte dal simulatore vengono usate come funzioni obiettivo. Il flusso dati costituito inoltre dai dati intermedi di elaborazione; i dati di input per i nodi del flusso di esecuzione sono posti sopra il nodo stesso, mentre i dati di output sono inseriti sotto il nodo di elaborazione.

camber layers 1...4 draft layers 1...4

twist layers 3...4 mesh-file

cfxprefile cfxppstfile

Output_forces

MORPHING

CFX_RUN

SELECT METRICS

area

mesh-file

Output_forces

Fx

Fz

Figura 5 - Modello di workflow per il problema di ottimizzazione di esempio

Il flusso di esecuzione del workflow costituito da tutti i nodi necessari per lesecuzione di una simulazione. In riferimento al problema in esame, il primo nodo, al quale sono passati in input tutte le variabili di progettazione, il nodo Service Task ANSA, il quale automaticamente aggiorna i valori delle variabili di progettazione per ogni differente configurazione proposta dallalgoritmo di ottimizzazione e genera come risultato un file [7]

mesh (mesh_file); in questo file viene memorizzata la struttura mesh della vela a seguito della esecuzione del processo di mesh morphing. Il secondo nodo il nodo di simulazione, realizzato come elemento Service Task (nodo BASH shell), che riceve come input il file mesh ed i file di sessione che contengono tutte le operazioni necessarie per configurare il modello CFD (Computational Fluid Dynamics), eseguire la simulazione ed estrarre i risultati, producendo in output un file di testo (Output_forces). Il terzo nodo un elemento Manual Task che, ricevendo in input il file di testo prodotto dal nodo precedente, per ogni design estrae le metriche usate per valutare le funzioni obiettivo. Le metriche valutate dal workflow sono: area del modello mesh della vela (area), forza motrice (valore assoluto di Fx) e momento di sbandamento (Fz). La prima metrica viene usata come variabile di progettazione; viene quindi inserito un ulteriore vincolo al problema di ottimizzazione relativo la dimensione massima della superficie della vela. Le rimanenti metriche sono usate per valutare le funzioni obiettivo del problema. Il workflow scientifico relativo lesempio proposto realizzato come un unico flusso di esecuzione ed costituito da un limitato numero di nodi; a partire da questo esempio possibile comprendere la funzione svolta da un workflow scientifico, il quale definisce il processo di esecuzione ed il flusso dati nella fase di simulazione per ciascun design determinato in fase di pianificazione del problema di ottimizzazione. Una importante osservazione riguarda la fase di esecuzione del workflow: ciascun nodo pu essere istanziato in macchine differenti e larchitettura di calcolo sottostante pu essere molto complessa; il workflow fornisce infatti una astrazione del processo di esecuzione.

Architettura di riferimento per i SWfMS

I sistemi di controllo per workflow scientifici sono strumenti necessari per la gestione dei workflow, in particolare per la fasi di esecuzione e monitoraggio. Il metodo di sviluppo dei SWfMS che verr analizzato riguarda levoluzione dei sistemi di controllo dei workflow scientifici a partire dai sistemi di controllo per business workflow. Sebbene i sistemi di controllo per workflow scientifici siano sviluppati come specializzazione dei BWfMS, gli obiettivi e le caratteristiche dei SWfMS sono differenti.

[8]

Prendendo in considerazione gli aspetti rilevanti nella costruzione di business workflow possibile rappresentare in modo schematico (Figura 6) il ciclo di vita nello sviluppo di workflow scientifici.

Scientific Problem Scientist

Discovering Process Improving Process

< use >

Statistics Execution Data

Shared Repository

Process Formal Description

< validate >

Modeling Process

BPMN 2.0 metamodel

Executing Process

Figura 6 - Ciclo di vita di un workflow scientifico

Solo recentemente stata proposta una prima architettura di riferimento per workflow scientifici (Lin & al., 2009), e soprattutto identificati i requisiti chiave: 1. Personalizzazione dello user interface ed apporto nella interazione con lutente I workflow scientifici non forniscono solo automazione nella esecuzione dei processi scientifici, ma considerano lapporto umano necessario per la personalizzazione della esecuzione del workflow attraverso la specifica di parametri applicativi e la rappresentazione dei risultati in base alla disciplina scientifica. 2. Supporto alla riproducibilit scientifica La riproducibilit il principio fondamentale nel metodo scientifico, ottenibile tramite informazioni di provenienza di ogni dato e la descrizione puntuale di ogni passo di esecuzione.

[9]

3. Servizi eterogenei e distribuiti ed integrazione degli strumenti software Complessi problemi scientifici hanno spesso la necessit di integrare diversi strumenti software eterogenei e distribuiti, che possono differire nei metodi di chiamata ed ambiente di esecuzione; questi vengono generalizzati come workflow task, creando un modello di astrazione rispetto la realizzazione dei singoli strumenti software e permettendo lintegrazione di molti servizi e strumenti, quali interfacce e protocolli di comunicazione. 4. Tipi di dati Ogni singolo dato manipolato allinterno del workflow viene rappresentato tramite un proprio tipo di dato, semplice o complesso. 5. Supporto alla computazione ad alto livello Grid computing e Cloud computing sono infrastrutture di calcolo di alto livello che, in modo trasparente allo scienziato, permettono di migliorare le prestazioni della esecuzione del workflow, soprattutto in relazione allutilizzo di grandi quantit di memoria e di risorse computazionali. 6. Monitoraggio del workflow e gestione degli errori Il monitoraggio della esecuzione del workflow in ogni punto del flusso di esecuzione e la gestione degli errori (con il minimo intervento umano) sono compiti necessari per garantire stabilit e congruenza nei passi di esecuzione; gli errori possono essere causati da eccezioni o fallimenti nella esecuzione di task o nei protocolli di comunicazione, in particolare per sistemi complessi. 7. Interoperabilit Diversi sistemi di esecuzione e monitoraggio dei workflow possono interoperare in progetti di ricerca di natura collaborativa, sia per quanto riguarda lo scambio di dati, che nella esecuzione di task e workflow da un sistema ad un altro. A partire da questi requisiti, sono state identificate le caratteristiche del sistema di controllo per workflow scientifici e larchitettura, la cui rappresentazione schematica riportata in Figura 7.

[ 10 ]

Sistema di controllo per workflow scientifici

Presentazione

Presentazione e Visualizzazione

Realizzazione del workflow

Gestione Workflow

altri Workflow Engine

Workflow Engine

Amministrazione e strumenti di monitoraggio

Gestione Task

Gestione dati e tipi di dato

Gestione delle informazioni di provenienza dei dati

Gestione dei Task

Livello Operativo

Ambienti di esecuzione

Sorgenti dati

Strumenti software

Servizi

Figura 7 - Architettura di riferimento per workflow scientifici

Process Definition Tools

Workflow Enactment Service Administration and Monitoring Tools Workflow Engines

Other Workflow Enactment Services Workflow Engines

Client Application

Worklist Handler

Tool Agent TYPICAL WEB SERVICES Invoked Application

Figura 8 - Architettura di riferimento per business workflow

[ 11 ]

Larchitettura per i SWfMS risulta essere molto simile alla architettura di riferimento dei sistemi di controllo per business workflow proposta dalla Workflow Management Coalition (WfMC) nel 1995 (WfMC, 1995); il diagramma del modello di riferimento dei sistemi di controllo per business workflow riportato in Figura 8. I sistemi di controllo per business workflow sono pi orientati al flusso di controllo e normalmente non permettono flussi di dati espliciti; al contrario, i sistemi di controllo per workflow scientifici sono pi orientati al flusso dati e questa caratteristica deve essere tenuta in considerazione durante lo sviluppo dei SWfMS. Lintroduzione della specifica BPMN 2.0 ha portato alla definizione di uno standard nella rappresentazione ed esecuzione dei business workflow; questo un ulteriore stimolo verso lo sviluppo di sistemi di controllo per workflow scientifici a partire da sistemi BWfMS, infatti la definizione di uno standard rientra nel requisito sulla riproducibilit scientifica del workflow. La specifica BPMN 2.0 costruita su un modello semantico formale (sviluppato come UML class diagrams) che viene integrato da ogni motore BPMN 2.0 come uno XML Schema ed usato nelle fasi di validazione e costruzione del workflow. Lo sviluppo dei sistemi SWfMS deve avvenire dunque come specializzazione dei BWfMS, e proprio a questo punto si inserisce il problema della formalizzazione del concetto di estensione del modello semantico per i sistemi di controllo di business workflow; sono state individuate due diverse categorie di estensione: 1. Estensione del modello semantico della specifica BPMN 2.0 2. Inserimento di funzionalit nei motori BPMN 2.0 Le funzionalit applicabili ai motori di esecuzione riguardano la corretta gestione dei nuovi elementi inseriti a seguito della estensione del modello semantico e linserimento di specifici componenti nei motori di esecuzione per BWfMS, utili nello sviluppo di un motore per SWfMS. Nel seguito verranno studiate le estensioni applicabili ai motori jBPM 5 ed Activiti, per lo sviluppo di due motori per SWfMS; per effettuare un confronto fra le due soluzioni, saranno implementate funzionalit simili ai due motori BPMN 2.0.

[ 12 ]

Capitolo 2

BPMN 2.0

La specifica BPMN 1.0 (Business Process Modeling Notation) stata sviluppata dal Business Process Management Institute (BPMI), ora diventato Object Management Group (OMG), e rilasciata nel maggio del 2004. BPMN stata adottata come un OMG standard nel febbraio del 2006. La specifica stata concepita per fornire una descrizione e regole di modellizzazione agli elementi dei business workflow in notazione grafica; i workflow sono rappresentati come flowchart, riprendendo lo stile degli UML activity diagrams. La specifica BPMN 2.0 (Business Process Model and Notation) rilasciata nel 2011, ha introdotto numerosi aggiornamenti rispetto le versioni precedenti; in particolare fornisce un modello semantico o metamodel, necessario per formalizzare ed uniformare le fasi di sviluppo ed esecuzione dei workflow. Riprendiamo i concetti chiave riguardanti i workflow, con particolare attenzione alla specifica BPMN 2.0. Processo Un processo una organizzata e coordinata sequenza di attivit, condotta da partecipanti, che agiscono e decidono con dati, informazioni e conoscenza per raggiungere un obiettivo. Partecipante Viene considerato partecipante qualsiasi attore che interagisce in un processo; gli attori possono essere persone umane oppure risorse digitali o virtuali (sistemi, macchine, processi). Scope context Uno scope definito come un contenitore di elementi e dati, e mantiene lo stato di ogni componente al suo interno; in un processo pu esistere una gerarchia di scopes, in cui nella radice si trova il processo e gli subscopes sono rappresentati dagli elementi Sub-Process. La specifica suddivide i componenti di un processo in cinque principali categorie: Flow objects, Data, Connecting objects, Swimlanes, Artifacts. Nella categoria Flow objects sono raggruppati tutti gli elementi principali di un workflow, quali Event, Activity e Gateway. Gli elementi Event si riferiscono ad eventi che intervengono durante lesecuzione del processo. Gli elementi Activity svolgono un determinato lavoro nel flusso di esecuzione del processo; nel caso di lavoro atomico si [ 13 ]

parla di elementi Task, mentre nel caso di un lavoro scomponibile si parla di elementi Sub-Process. Gli elementi Gateway sono usati per controllare il flusso di esecuzione del processo. La categoria Data 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. La categoria Connecting objects 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. Gli elementi della categoria Swimlanes permettono di raggruppare gli elementi del workflow per differenti partecipanti e si distinguono in Pools e Lanes. Gli elementi Pool rappresentano i partecipanti in una collaborazione. Gli elementi Lanes corrispondono a partizioni del processo e vengono usati per organizzare e catalogare le Activity. Gli Artifacts sono elementi che forniscono informazioni addizionali ad elementi o al processo, distinti in Group e Text annotation. Gli elementi Group sono elementi grafici che permettono di raggruppare elementi che fanno parte 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. I dettagli riguardanti la rappresentazione, lesecuzione e linterazione di ognuno di questi elementi sono descritti nella specifica BPMN 2.0 (OMG, 2011); nel seguito verr considerato solo un gruppo ristretto di elementi, saranno dunque valutate le scelte e le possibili estensioni applicabili a questi elementi. Gli elementi della specifica BPMN 2.0 che, in base anche a scelte aziendali, non verranno trattati sono: Swimlanes (Pools, Lanes): i workflow spesso vengono gestiti da un solo attore umano e non sono presenti collaborazioni in un singolo workflow.

[ 14 ]

Messaggi (Message events, Message Task): i messaggi sono legati agli elementi della categoria Swimlanes, permettono di coordinare lesecuzione del workflow tra pi partecipanti.

Business Rules: le business rules sono regole di decisione che definiscono o limitano lesecuzione di un workflow; una scelta di progetto alternativa riguarda linserimento di file o parametri di configurazione del workflow.

Artifacts: secondo la specifica BPMN 2.0 le annotazioni possono essere usate per specificare il comportamento di elementi del workflow (ad esempio Gateways) in modo testuale; la struttura del workflow dovr invece sempre contenere espressioni e regole ben formate nelle istanze dei flow elements.

Error Handling (Exceptional flow, Compensation): la gestione degli errori un aspetto importante per i SWfMS, in questo lavoro di tesi tuttavia non vengono trattati.

BPMN 2.0 metamodel

La specifica W3C XML Schema introduce il concetto di XML schema definition, che descrive la struttura di un documento XML. Con XSDL (XML Schema Definition Language) si fa riferimento al linguaggio usato per creare gli schema definitions in XML. La conoscenza dei concetti generali riguardanti gli XML Schema sono indispensabili per lo studio del modello semantico nella specifica BPMN 2.0. La specifica BPMN 2.0 ha acquisito una definizione formale con lintroduzione di un modello semantico nella forma di metamodel. Questo metamodel viene integrato in ogni motore di esecuzione di workflow come uno XSD Schema, attraverso un file XML che realizza la definizione dello schema in linguaggio XSDL. La definizione formale del BPMN 2.0 metamodel, con nome BPMN20.xsd, raggiungibile allindirizzo <http://www.omg.org/spec/BPMN/20100501/>. Normalmente uno strumento di modellizzazione di workflow non presenta la necessit di lavorare direttamente con il metamodel; questo diventa invece necessario quando il metamodel deve essere esteso per integrare nuovi elementi e funzionalit. Il modello semantico della specifica BPMN 2.0 ha permesso inoltre di formalizzare la semantica di esecuzione del processo e di tutti i nodi che lo compongono. Nel seguito, i componenti di un modello di workflow saranno chiamati elementi, mentre gli oggetti che rappresentano le istanze degli elementi del workflow a seguito della esecuzione del processo saranno chiamati nodi.

[ 15 ]

Ogni modello di workflow costituito di un flusso dati ed un flusso di esecuzione. Il flusso dati comprende gli elementi DataObject, Data Association, Data Input e Data Output. Gli elementi DataObject, Data Input e Data Output vengono associati agli elementi Activity o Gateway attraverso gli elementi Data Association per definire il flusso dei dati nel processo. Gli elementi Data Association possono eventualmente contenere un attributo transformation che specifica la trasformazione sui dati in ingresso. Per spiegare il flusso di esecuzione del workflow, la specifica BPMN 2.0 ha introdotto il concetto teorico di token. Il flusso di esecuzione definisce lordine di esecuzione dei nodi del workflow. Un processo viene istanziato quando interviene uno dei possibili Start Event applicabili al processo; per ogni istanza del processo viene creato un token, il quale deve attraversare i nodi del processo. Un nodo pu essere eseguito quando riceve un token, ed alla sua terminazione deve rilasciare il token nel flusso di esecuzione; ogni token creato nella esecuzione del processo deve essere consumato da un End Event. La corretta gestione del flusso di esecuzione del processo e la corretta definizione e validazione di ogni suo elemento sono richieste dalla specifica BPMN 2.0 ed allo stesso tempo sono fondamentali per garantire la riproducibilit scientifica della simulazione, attraverso la definizione del modello di workflow.

XSD Schema namespace

Il termine namespace si riferisce ad un particolare costrutto dello XML Schema, il cui principale scopo quello di fornire un nome univoco che possa essere associato ad un specifico soggetto (ad esempio una organizzazione), nella forma di Uniform Resource Identifier (URI) e viene usato come contenitore per gli elementi dello XML Schema; utile osservare che il namespace pu essere visto come un riferimento generico e pu non essere associato ad alcuna risorsa esistente (risorse quali ad esempio XML schema o pagine HTML). Il namespace viene dichiarato usando uno speciale attributo che inizia con le lettere xmlns, seguito dal prefisso e la dichiarazione dello namespace; il prefisso viene usato come un identificatore per il namespace. Il costrutto namespace risulta molto utile nelle istanze di XML Schema per distinguere gli elementi usati, anche in fase di validazione del documento XML che rappresenta listanza di workflow. Il concetto di namespace diventa di fondamentale importanza nella estensione del modello semantico della specifica BPMN 2.0, in particolare per la fase di validazione

[ 16 ]

del modello. Nel seguito si prenderanno in considerazione alcuni elementi della specifica BPMN 2.0 e la loro formalizzazione nel documento XML che rappresenta listanza del workflow su elementi dichiarati nel metamodel.

Workflow definition
Ogni workflow definito da una specifica rappresentazione grafica e da un relativo documento XML basato sul BPMN 2.0 Schema definition. Nel seguente esempio viene presentato un semplice workflow che integra alcuni elementi della specifica BPMN 2.0 (Figura 9) e viene fornito il corrispondente documento in formato XML (Esempio 1).

DataInput

First step elaboration

Sub-Process Elaboration

DataOutput=0

DataOutput

Figura 9 - Rappresentazione grafica workflow di esempio

A partire da questo esempio possiamo andare a studiare nel particolare alcuni elementi della specifica BPMN 2.0, che verranno nel seguito ripresi nella caratterizzazione delle estensioni. Lo studio degli elementi della specifica BPMN 2.0 si concentra sulla definizione degli elementi stessi allinterno del documento XML che rappresenta il modello di workflow; la gestione della fase di esecuzione di specifici elementi verr affrontata invece nello studio della estensione delle funzionalit dei motori di esecuzione. Esempio 1 - Definizione di un workflow di esempio
<?xml version="1.0" encoding="UTF-8"?> <definitions id="Definition" targetNamespace="http://www.esteco.com/Example1" typeLanguage="http://www.java.com/javaTypes" expressionLanguage="http://www.mvel.org/2.0" xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.omg.org/spec/BPMN/20100524/MODEL BPMN20.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema"

[ 17 ]

xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI" xmlns:dc="http://www.omg.org/spec/DD/20100524/DC" xmlns:di="http://www.omg.org/spec/DD/20100524/DI"> <process isExecutable="true" id="MainProcess" name="MainProcess" > <!-- process variables --> <dataObject id="DataInput" itemSubjectRef="xsd:double" /> <dataObject id="DataOutput" itemSubjectRef="xsd:double" /> <!-- nodes --> <startEvent id="_1" name="Start" /> <dataObjectReference dataObjectRef="DataInput" id="RefInput"/> <dataObjectReference dataObjectRef="DataOutput" id="RefOutput"/> <task id="_2" name="First Step Elaboration"> <ioSpecification> <dataInput id="_2_Input" name="taskDataInput" /> <dataOutput id="_2_Output" name="taskDataOutput" /> <inputSet> <dataInputRefs>_2_Input</dataInputRefs> </inputSet> <outputSet> <dataOutputRefs>_2_Output</dataOutputRefs> </outputSet> </ioSpecification> <dataInputAssociation> <sourceRef>RefInput</sourceRef> <targetRef>_2_Input</targetRef> </dataInputAssociation> <dataOutputAssociation> <sourceRef>_2_Output</sourceRef> <targetRef>RefOutput</targetRef> </dataOutputAssociation> </task> <exclusiveGateway id="_3" name="ApprovalStep" default="_3_5"> <incoming>_2_3</incoming> <outgoing>_3_4</outgoing> <outgoing>_3_5</outgoing> </exclusiveGateway> <endEvent id="_4" name="FailureEndProcess" > <terminateEventDefinition/> </endEvent> <subProcess id="_5" name="Sub-Process Elaboration" > <standardLoopCharacteristics loopMaximum="5" testBefore="false"> <loopCondition> <![CDATA[RefSubProcessData=0]]> </loopCondition> </standardLoopCharacteristics> <dataObject id="SubProcessData" name="SubProcess DataObject"/> <dataObjectReference dataObjectRef="SubProcessData" id="RefSubProcessData"/> </subProcess> <endEvent id="_6" name="EndProcess" /> <!-- connections --> <sequenceFlow id="_1-_2" sourceRef="_1" targetRef="_2" />

[ 18 ]

<sequenceFlow id="_2-_3" sourceRef="_2" targetRef="_3" /> <sequenceFlow id="_3_4" sourceRef="_3" targetRef="_4"> <conditionExpression> <![CDATA[${!DataOutput=0}]]> </conditionExpression> </sequenceFlow> <sequenceFlow id="_3_5" sourceRef="_3" targetRef="_5"> <conditionExpression></conditionExpression> </sequenceFlow> <sequenceFlow id="_5-_6" sourceRef="_5" targetRef="_6" /> </process> </definitions>

Data Object
Gli elementi Data Object corrispondono a variabili nel processo e rappresentano oggetti semplici o complessi, dati singoli o collezioni di dati. I Data Object non influenzano direttamente il flusso di esecuzione del processo, infatti i token di esecuzione non seguono le Data Associations, e vengono associati ad elementi Activity oppure Gateway; questi elementi sono di particolare importanza nei workflow scientifici, in quanto permettono di descrivere il flusso dei dati allinterno del processo. Ogni Data Object associato ad un proprio tipo di dato, semplice o complesso, la cui definizione deve essere inserita nel BPMN 2.0 Schema definition oppure come riferimento ad un tipo di dato semplice presente nella specifica XML Schema. Nella definizione del workflow possibile inserire un riferimento ad un tipo di dato attraverso lelemento itemDefinition - riferimento esterno rispetto lelemento process. Esempio 2 - Inserimento di DataObjects in una istanza di workflow associati ad un proprio tipo di dato semplice definito nella specifica XML Schema.
<?xml version="1.0" encoding="UTF-8"?> <definitions id="Definition" xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL" xmlns:xsd="http://www.w3.org/2001/XMLSchema" > <itemDefinition id="_StringItem" structureRef="xsd:string" /> <itemDefinition id="_DoubleItem" structureRef="xsd:double" /> <process id="MainProcess" name="MainProcess" isExecutable="true" > <!-- process variables --> <dataObject id="owner" itemSubjectRef="_StringItem" /> <dataObject id="sum" itemSubjectRef="_DoubleItem" /> </process> </definitions>

[ 19 ]

Gli elementi DataInput e DataOutput della specifica BPMN 2.0 possono essere visti come un riferimento a DataObject e Property dello scope globale; questi sono usati allinterno di un elemento InputOutputSpecification per associare rispettivamente i dati di input ed i dati di output per elementi Activity oppure Event.

Activity
Con il termine Activity si fa riferimento allinsieme di elementi della specifica BPMN 2.0 che svolgono un determinato lavoro (atomico o scomponibile) allinterno del flusso di esecuzione di un workflow. Le categorie principali di Activity sono Task e Sub-Process. Tutti gli elementi Activity condividono attributi e caratteristiche comuni, quali stato di esecuzione e transizioni di stato. Il ciclo di vita di un nodo Activity pu essere scomposto in una struttura complessa di stati di esecuzione. Lesecuzione di una Activity pu essere ripetuta; in questo caso lelemento deve specificare se si tratta di un ciclo condizionale - loop - oppure di una multi-instance, in cui linsieme delle istanze dellelemento possono essere eseguite in sequenza o in parallelo.

Loop Activity e Multiple Instances Activity

Gli elementi Loop Activity si riferiscono ad una particolare categoria di elementi Activity, i quali ripetono lesecuzione della Activity in base al valore di una condizione valutata al termine (o allinizio) di ogni istanza del ciclo. Gli elementi Multiple Instances Activity invece si riferiscono ad una categoria di elementi Activity usati per lesecuzione sequenziale o parallela di un insieme di istanze del nodo Activity; ad ogni istanza pu essere assegnato un differente valore per un parametro in ingresso. La specifica BPMN 2.0 afferma che gli elementi Loop Activity e Multiple Instances Activity sono costituiti da un nodo Outer Activity ed un nodo Inner Activity; lelemento Outer Activity non viene rappresentato nella descrizione del modello e viene usato come contenitore per la gestione della esecuzione delle istanze dellelemento Inner Activity. Lelemento Inner Activity rappresenta la definizione dellelemento Activity del modello di workflow. Riguardo gli elementi Loop Activity, il nodo Outer Activity esegue una nuova istanza del nodo Inner Activity finch risulta vera la condizione stabilita dallespressione inserita nellattributo loopCondition dellelemento standardLoopCharacteristics, con un numero massimo di istanze stabilite dallattributo loopMaximum.

[ 20 ]

Gli elementi Multiple Instances Activity generano un numero di istanze del nodo Inner Activity in base al numero intero specificato dallattributo loopCardinality dellelemento MultiInstanceLoopCharacteristics, oppure in base alla

cardinalit di uno specifico elemento Data Input istanziato come collezione di dati.

Task
La specifica BPMN 2.0 definisce Task una Activity atomica o transazione, allinterno del flusso di esecuzione del processo; i Task sono raggruppati in diverse categorie, tra le quali User Task, ServiceTask, ScriptTask. Alcune tipologie di task, in particolare i Service Task, presentano una interfaccia, nella quale vengono definiti gli elementi DataInput, DataOutput, InputSet ed OutputSet. Gli elementi DataInput e DataOutput sono riferiti rispettivamente ad dati di input ed output del nodo Task; questi sono associati ad un tipo di dato semplice, definito dalla specifica XML Schema, oppure definito come riferimento, attraverso la propriet itemSubjectRef. Gli elementi InputSet definiscono gli insiemi di elementi DataInput con le quali una istanza del task pu essere eseguita: una istanza del task pu essere eseguita solamente quando sono disponibili tutti gli elementi DataInput specificati in uno degli InputSet (con precedenza rispetto lordine di definizione). Service Task La specifica BPMN 2.0 definisce lelemento Service Task: A Service Task is a Task that uses some sort of service, which could be a Web Service or an automated application. I concetti di estensione del modello semantico e delle funzionalit dei motori BPMN coinvolgono, in questo lavoro di tesi, in modo particolare gli elementi ServiceTask, ed intervengono a diversi livelli: Caratterizzazione del Task attraverso nuovi attributi, propriet ed elementi Gestione e personalizzazione della interfaccia Gestione dei tipi di dati

Gli ultimi due punti riguardano caratteristiche disponibili o da inserire nei motori di esecuzione dei processi.

[ 21 ]

Sub-Process
I sottoprocessi corrispondono ad un flusso di esecuzione contenuto in uno scope interno al processo principale; sono spesso usati per aggregare un insieme di attivit corrispondenti ad una funzione ben definita nel processo principale, oppure un insieme di attivit ripetute ciclicamente; inoltre possono essere usati per la gestione degli errori e per operazioni di compensazione. I sottoprocessi Embedded sono definiti allinterno del processo principale, mentre gli elementi Callable Subprocess creano un riferimento ad un processo esterno. La specifica BPMN 2.0 afferma che i sottoprocessi Embedded non possono avere una interfaccia diretta, questo significa che gli elementi Data Input e Data Output non possono essere definiti internamente il sottoprocesso come riferimenti di DataObject del processo a livello superiore.

[ 22 ]

Capitolo 3

Estensibilit del modello semantico

La specifica BPMN 2.0 costituita di un modello semantico che descrive la struttura di ogni elemento, linterazione fra i diversi elementi e la semantica di esecuzione di ogni elemento del workflow. La specifica stata costruita per essere estensibile, mediante linserimento di nuovi elementi ed attributi al modello semantico. Nel seguito del capitolo viene valutato dal punto di vista formale il concetto di Extension, per poi affrontare i diversi metodi di applicabilit nel modello semantico in base a diversi costrutti della specifica XML Schema.

BPMN 2.0 Extensibility

Il modello semantico della specifica BPMN 2.0 pu essere esteso attraverso costrutti differenti. In questa sezione vengono studiate le modalit di estensione del BPMN 2.0 metamodel, a partire dalla modalit per addizione descritta nella specifica BPMN 2.0, quindi verr trattata la modalit di estensione di un elemento come sottoclasse di un elemento esistente ed infine il costrutto Redefine della specifica XML Schema. Per ognuno dei metodi di estensione necessario verificare che il modello costruito sia BPMN-compliant, quindi completamente aderente alla specifica BPMN 2.0, ed assicurare che la validazione dei workflow costruiti su tale modello sia corretta. Non si far mai riferimento alla rappresentazione grafica della estensione allinterno dei tool di modellizzazione, si far invece riferimento alla gestione della extension nelle fasi di validazione ed esecuzione del workflow nei motori BPMN 2.0.

Estensione per addizione

Ogni elemento discendente dellelemento BaseElement della specifica BPMN 2.0, pu essere esteso con elementi ed attributi addizionali. La sezione 8.2.3 della specifica BPMN 2.0 affronta il concetto di estensibilit del metamodel per addizione in termini di inserimento di nuovi elementi ed attributi agli elementi standard gi presenti nel metamodel. Nella sezione 8.2.3 della specifica BPMN 2.0 riportato il diagramma extension class diagram; lestensione di un elemento viene suddivisa in definizione dellelemento, [ 23 ]

definizione degli attributi e valore di ogni attributo. Inoltre stato introdotto un caso duso per la modalit di estensione per addizione.

XML Schema BPMN Metamodel Definition Document instanceOf import

XML BPMN Model Definition Document

import

XML Schema Extension Definition Document

Figura 10 - Extension: struttura del documento XML Schema

Lestensione del metamodel viene inserita in un nuovo documento XML Schema, nel quale vengono specificati i nuovi elementi ed attributi; questi nuovi componenti potranno essere inseriti in qualunque elemento del BPMN 2.0 metamodel in fase di istanza del modello, questo significa che non sono associati ad uno specifico elemento. Attraverso lo schema di Figura 10 risulta pi semplice comprendere come associare un nuovo documento XML Schema, estensione del BPMN 2.0 metamodel, al documento che rappresenta il modello di workflow. I nuovi elementi da inserire nella estensione sono spesso raggruppati nello XML Schema in un elemento chiamato dalla specifica XML Schema come named model group, costituito di modelli di contenuto riusabili e rappresentato in linguaggio XSDL con lelemento group. Riguardo linserimento di singoli elementi, la dichiarazione dellelemento pu essere effettuata esternamente allelemento group. Per ogni nuovo elemento possibile definire gli attributi e il tipo di dato semplice o complesso. I nuovi attributi inseriti nella extension del metamodel invece sono dichiarati in un elemento dello XML Schema chiamato attribute groups oppure singolarmente come figli dellelemento schema. LEsempio 3 considera un caso particolare di XML Schema Extension Definition Document: il target namespace del documento ha prefisso esteco, non riferito allo standard namespace del modello semantico BPMN 2.0. LEsempio 5 mostra la definizione di un workflow di esempio; si pu osservare come gli elementi, la cui definizione contenuta nel documento XML della estensione, devono essere inseriti con il prefisso relativo il nuovo namespace.

[ 24 ]

Esempio 3 - Estensione dellelemento Task della specifica BPMN 2.0. Documento Extension.xsd: definizioni di named model group, singolo elemento, attribute group ed attributo globale.
<?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:esteco="http://www.esteco.com" xmlns:="http://www.esteco.com" xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL" targetNamespace="http://www.esteco.com" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xsd:import namespace="http://www.omg.org/spec/BPMN/20100524/MODEL" schemaLocation="Semantic.xsd"/> <!-- Named model group --> <xsd:group name="OwnerPriviledges"> <xsd:sequence> <xsd:element name="agent" type="tAgentType" minOccours="1" maxOccours="1" /> <xsd:element name="taskPriviledges" type="tTaskPrivilege" minOccours="1" maxOccours="unbounded" /> </xsd:sequence> </xsd:group> <xsd:complexType name="tTaskPrivilege" abstract="false"> <xsd:attribute name="name" type="xsd:string" /> <xsd:attribute name="granted" type="xsd:boolean" /> </xsd:complexType> <xsd:simpleType name="tAgentType"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="SYSTEM" /> <xsd:enumeration value="ADMINISTRATOR" /> </xsd:restriction> </xsd:simpleType> <!-- Single element --> <xsd:element name="path" type="tPath"/> <xsd:complexType name="tPath"> <xsd:attribute name="defaultValue" type="xsd:anyURI"/> </xsd:complexType> <!-- Attribute groups --> <xsd:attributeGroup name="listAttributes"> <xsd:attribute name="idProject" type="xsd:string" /> <xsd:attribute name="version" type="xsd:decimal" /> </xsd:attributeGroup> <!-- Single attribute --> <xsd:attribute name="shortDescription" type="xsd:string" /> </xsd:schema>

[ 25 ]

Esempio 4 - Documento ExtensionBPMN20.xsd: modello semantico completo.

<?xml version="1.0" encoding="UTF-8"?> <xsd:schema elementFormDefault="qualified" attributeFormDefault="unqualified" xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI" targetNamespace="http://www.omg.org/spec/BPMN/20100524/MODEL"> <xsd:import namespace="http://www.esteco.com" schemaLocation="Extension.xsd"/> <xsd:include schemaLocation="BPMN20.xsd"/> </xsd:schema>

Esempio 5 - Esempio di definizione di workflow con estensione named model group ed attributo globale allelemento Task della specifica BPMN 2.0.
<?xml version="1.0" encoding="UTF-8"?> <definitions id="Definition" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.esteco.com ExtensionBPMN20.xsd http://www.omg.org/spec/BPMN/20100524/MODEL http://www.omg.org/spec/BPMN/20100501/BPMN20.xsd" xmlns:esteco="http://www.esteco.com" > <extension definition="esteco:OwnerPriviledges" mustUnderstand="true" /> <process id="MainProcess" name="MainProcess" isExecutable="true" > <serviceTask id="_1_2" name="customer" esteco:shortDescription ="test"> <extensionElements> <esteco:agent>SYSTEM</esteco:agent> <esteco:taskPriviledges name="setClients" granted="true" /> </extensionElements> </serviceTask> </process> </definitions>

Estensione per derivazione

Come per la modalit di estensione per addizione, la modalit di estensione per derivazione permette di estendere la definizione degli elementi della specifica BPMN 2.0 con elementi ed attributi addizionali: sufficiente infatti estendere la definizione dellelemento del BPMN 2.0 metamodel in un nuovo XML Schema (Figura 10). A differenza della modalit di estensione per addizione, gli elementi definiti nella estensione per derivazione non vengono inseriti allinterno dellelemento extension nel modello di workflow.

[ 26 ]

Questa modalit di estensione, prevista dalla specifica XML Schema, non viene tuttavia trattata dalla specifica BPMN 2.0. La modalit di estensione per derivazione permette di specializzare un elemento esistente con linserimento di nuovi elementi ed attributi al suo interno; la specifica XML Schema realizza questa estensione attraverso i concetti di complex type derivation e sobstitution group. Questo metodo di estensione del BPMN 2.0 metamodel introduce una importante capacit: linserimento di nuovi elementi nel modello semantico allo stesso livello degli elementi standard della specifica BPMN 2.0, quindi discendenti diretti dellelemento process. Esempio 6 - Creazione di un elemento calculatorTask come estensione dellelemento Task, con la definizione di un attributo operation.
<xsd:element name="calculatorTask" type="tCalculatorTask" substitutionGroup="bpmn:flowElement"/> <xsd:complexType name="tCalculatorTask"> <xsd:complexContent> <xsd:extension base="bpmn:tTask"> <xsd:attribute name="operation" type="xsd:string" /> </xsd:extension> </xsd:complexContent> </xsd:complexType>

Intuitivamente questa capacit risulta indispensabile al fine ottenere la specializzazione degli elementi del workflow, quindi per risolvere il primo ostacolo verso la formalizzazione di un sistema di controllo di workflow scientifici a partire da un generico BPMS. Purtroppo questa modalit di estensione non stata esplicitamente trattata nella specifica BPMN 2.0, questo significa che i motori BPMN potrebbero non supportare questa modalit di estensione. Sia il metodo di estensione per derivazione che il metodo di estensione per addizione permettono di specificare un nuovo target namespace nel documento XML Schema Extension Definition Document. Questa caratteristica non viene descritta nella specifica BPMN 2.0, tuttavia viene supportata dalla specifica XML Schema.

XML Schema Redefine

La specifica XML Schema contiene il costrutto Redefine, usato per ridefinire specifici componenti di un modello XML Schema. Lelemento redefine seleziona lo schema da ridefinire attraverso lattributo schemaLocation; inoltre il nuovo XML Schema deve avere lo stesso target namespace dello schema da ridefinire. [ 27 ]

Allo stesso modo del metodo di estensione per derivazione, la modalit di estensione per ridefinizione dei componenti del metamodel non viene trattata dalla specifica BPMN 2.0. Esempio 7 - Ridefinizione dellelemento dataStore del BPMN 2.0 metamodel, con linserimento di un nuovo attributo storeMode.
<?xml version="1.0" encoding="UTF-8"?> <xsd:schema elementFormDefault="qualified" attributeFormDefault="unqualified" xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI" targetNamespace="http://www.omg.org/spec/BPMN/20100524/MODEL"> <xsd:redefine schemaLocation="BPMN20.xsd"> <xsd:element name="dataStore" type="tDataStore" substitutionGroup="rootElement"/> <xsd:complexType name="tDataStore"> <xsd:complexContent> <xsd:extension base="tDataStore"> <xsd:attribute name="storeMode" type="xsd:string"/> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:redefine> </xsd:schema>

Il metodo di estensione per ridefinizione, a differenza degli altri due metodi, non permette di specificare un target namespace diverso dal namespace del modello semantico della specifica BPMN 2.0. Nei prossimi capitoli, per ognuno dei motori di esecuzione di workflow, verr studiata lapplicabilit dei metodi di estensione presentati in questo capitolo.

[ 28 ]

Capitolo 4

JBoss jBPM 5
Il framework open-source JBoss BPM1 include numerosi strumenti per lo sviluppo dei business workflow e la gestione del corrispondente ciclo di vita. Il motore di esecuzione, sviluppato in linguaggio Java e basato sulla specifica BPMN 2.0, pu essere esteso per inserire nuove funzionalit richieste nella realizzazione di un sistema di controllo per workflow scientifici. Il motore di esecuzione dei processi del framework jBPM 5 pu essere usato come ambiente di esecuzione standalone ed integrato come libreria in un progetto Java, oppure pu essere eseguito come servizio, eventualmente in un sistema cloud. Il framework jBPM 5 usufruisce del progetto JBoss Drools2, definito come Business Logic Integration Platform (BLiP), il quale fornisce un ambiente completo con cui poter gestire, fra le altre, lesecuzione dei workflow. Le Core Engine API di jBPM 5 appunto permettono di comunicare con il motore JBoss Drools.

Core Engine
Linterazione con il motore BPMN del framework jBPM 5 avviene attraverso le API pubbliche, necessarie per caricare i processi ed eseguirli; la trattazione completa accessibile nella documentazione online di jBPM 5. Il funzionamento viene descritto schematicamente dalla Figura 11; le classi principali sono: Knowledge base, che contiene i riferimenti ai documenti in formato XML con la definizione del processo, Stateful knowledge session, usata per comunicare con il motore di esecuzione jBPM e con la Knowledge base usata per eseguire una istanza di un processo.

Process Definition

Knowledge base

Stateful knowledge session

Process instance

Figura 11 - JBoss jBPM Core Engine API

1 2

http://www.jboss.org/jbpm http://www.jboss.org/drools

[ 29 ]

Struttura ed istanza del workflow

Il motore jBPM 5 deve effettuare tre principali operazioni: validazione della definizione del workflow, creazione del modello di workflow ed esecuzione della istanza del processo. La fase di creazione del modello porta alla costruzione della struttura del workflow, mediante limplementazione dei nodi che lo compongono. La fase di esecuzione di una istanza del workflow deve partire dalla creazione delle istanze di ogni nodo del workflow. Ogni elemento nella definizione del workflow viene associato dal motore jBPM 5 ad un opportuno Node Handler, usato per validare la definizione dellelemento e per la creazione di una implementazione del relativo nodo. Ogni nodo inoltre viene associato ad una opportuna Node Instance in fase di esecuzione di una istanza del processo.

Modello semantico della specifica BPMN 2.0

Il BPMN 2.0 metamodel inserito nel core engine jBPM nella directory di progetto JBPM::BPMN2/src/main/resources/META-INF/; il modello semantico pu essere esteso, come descritto nel Capitolo 3, inserendo un documento XML Schema Extension Definition Document nella directory ./resources/META-INF/ di un nuovo progetto Java (che includa le librerie jBPM 5); questa soluzione preferibile rispetto linserimento del modello semantico esteso nel core del motore jBPM 5. Limplementazione di ognuna delle modalit di estensione del modello semantico della specifica BPMN 2.0 descritte nel Capitolo 3, ha portato alla conclusione che le modalit di estensione per addizione e per derivazione sono supportate dal motore jBPM 5, mentre la modalit XML Schema Redefine non supportata. Diversi test hanno evidenziato in particolare come le modalit di estensione per addizione e per derivazione, anche con lapplicazione di un custom namespace al documento XML Schema Extension Definition Document, vengono correttamente validate dal motore jBPM 5. Nella implementazione della modalit XML Schema Redefine si verifcato invece come gli elementi e gli attributi ridefiniti non vengono rilevati dal motore jBPM 5; questo significa che, gi in fase di validazione, i nuovi elementi ed attributi del modello di workflow non sono riconosciuti come componenti BPMN-compliant.

[ 30 ]

Loop Activity
Lesecuzione degli elementi Loop Activity e Multiple Instances Activity (Task o SubProcess) viene gestita dal motore jBPM 5 attraverso la creazione di un elemento Outer Activity, usato come contenitore per lelemento Inner Activity. Internamente lelemento Outer Activity sono definiti 3 elementi: uno Start Node, il nodo Inner Activity ed uno End Node. Questi nodi interni sono nascosti, sia nella struttura del workflow, che in fase di esecuzione della istanza di processo. Il motore jBPM 5 non ha implementato la gestione degli elementi Loop Activity, mentre per la categoria Multiple Instances Activity sono stati implementati solo gli elementi Sub-Process. Nel seguito verr analizzata la realizzazione di una estensione dellelemento Sub-Process relativa la funzionalit Loop Activity.

Service Task
Lelemento Service Task nel motore jBPM 5 deve essere associato ad un proprio handler (procedura) di esecuzione prima di poter eseguire una istanza di workflow; un Item Handler viene definito come un handler relativo lesecuzione di una particolare classe di oggetti BPMN che non possono essere riconosciuti come oggetti standard dal motore BPMN. Ogni handler di esecuzione deve essere registrato nella Knowledge base per poter essere usato allinterno di una istanza di processo. jBPM 5 permette linserimento di elementi Service Task con interfaccia dati di input ed output personalizzata; questa modalit, descritta nella documentazione ufficiale (Domain-specific processes), risolve solo in parte il problema della estensione delle funzionalit dei nodi Service Task.

Analisi di una estensione dellelemento Service Task

Lelemento Service Task pu essere esteso attraverso una delle modalit di estensione del modello semantico della specifica BPMN 2.0 presentate nel Capitolo 3. Si consideri la modalit di estensione per derivazione con nuovo target namespace. Lelemento Service Task esteso pu essere riconosciuto dal motore jBPM 5 solo attraverso linserimento nella Knowledge base di un riferimento ad una classe che associa il nome dellelemento ed il relativo namespace con lopportuno handler di esecuzione. NellEsempio 8 viene creata una classe con il riferimento per lelemento calculatorTask con prefisso esteco al relativo handler; questo elemento stato definito nellEsempio 6 del Capitolo 3.

[ 31 ]

Questo riferimento relativo lo handler per lelemento estensione del Service Task deve quindi essere inserito come parametro di configurazione per la costruzione del Knowledge base. NellEsempio 9 viene fornito il codice per registrare lo handler per lelemento calculatorTask. Esempio 8 - Definizione del riferimento elemento calculatorTask - handler
import org.drools.xml.DefaultSemanticModule; public class EstecoBpmnSemanticModule extends DefaultSemanticModule { public static final String ESTECO_URI = "http://www.esteco.com"; public EstecoBpmnSemanticModule() { super(ESTECO_URI); CalculatorNodeHandler nodeHandler = new CalculatorNodeHandler(); addHandler("calculatorTask", nodeHandler); } }

Esempio 9 - Registrazione dello handler per lelemento calculatorTask

import org.drools.compiler.PackageBuilderConfiguration; public class BPMEngine { public static void main(String[] args) { PackageBuilderConfiguration builderConfiguration = new PackageBuilderConfiguration(); builderConfiguration.getSemanticModules() .addSemanticModule(new EstecoBpmnSemanticModule()); KnowledgeBuilder kbuilder KnowledgeBuilderFactory .newKnowledgeBuilder(builderConfiguration); kbuilder.add(ResourceFactory.newFileResource(bpmnFile), ResourceType.BPMN2); KnowledgeBase kbase = kbuilder.newKnowledgeBase(); } }

Questa stessa funzionalit pu essere ottenuta inserendo una nuova classe Node Handler (estensione della classe TaskHandler) associata al nodo, una nuova classe Node (estensione della classe WorkItemNode) ed una nuova Node Instance (estensione della classe WorkItemNodeInstance); la Node Instance deve essere registrata tramite la classe NodeInstanceFactoryRegistry prima di eseguire una istanza del processo. La classe Node Handler necessaria per eseguire una istanza del nodo, mentre la classe Node definisce limplementazione del nodo e la classe Node Instance definita come limplementazione a runtime del nodo.

[ 32 ]

Questo secondo metodo permette inoltre di estendere le funzionalit dellelemento allinterno del motore jBPM 5, ad esempio per la gestione degli elementi ed attributi inseriti come estensione in un XML Schema Extension Definition Document.

Sub-Process
Il nodo Sub-Process definito come un contenitore di nodi e variabili. Il motore jBPM 5 implementa il nodo Sub-Process come istanza della classe CompositeNode. Il nodo Sub-Process inoltre include un nodo Inner Activity, implementazione della classe CompositeContextNode, ed una Variable scope; questi componenti sono usati per definire il contesto di esecuzione del sottoprocesso.

Analisi della estensione Sub-Process Loop Activity

Una estensione applicabile allelemento Sub-Process riguarda limplementazione dellelemento Sub-Process Loop Activity. In Figura 12 viene analizzata sua una possibile realizzazione.

CompositeNode (Outer Activity)

CompositeContextNode (Inner Activity) Split Sub-Process

Join

Event Listener

Figura 12 - Struttura del nodo Sub-Process Loop Activity

Lelemento Outer Activity viene implementato come una estensione della classe CompositeNode; internamente devono essere definiti il nodo Split, usato come Start Node, il nodo Inner Activity, corrispondente alla realizzazione del nodo Sub-Process, ed il nodo Join, usato come End Node. Il nodo Inner Activity viene implementato come estensione della classe CompositeContextNode. Il nodo Outer Activity deve contenere un elemento Event Listener, usato per catturare i segnali di terminazione di esecuzione di ogni istanza del loop.

[ 33 ]

Questa stessa struttura deve essere realizzata anche per la fase di esecuzione di una istanza del nodo Sub-Process Loop Activity. Le estensioni presentate in questo capitolo, relative gli elementi Service Task e SubProcess Loop Activity, saranno riprese nel Capitolo 6 per la realizzazione di una definizione di workflow per il motore jBPM 5 ed il confronto delle prestazioni con il motore Activiti.

[ 34 ]

Capitolo 5

Alfresco Activiti
Il framework Alfresco Activiti3 un BPM system inserito allinterno del progetto Alfresco ECM, il cui sviluppo ha preso corpo dalla esperienza maturata con il framework JBoss BPM. Come per il framework jBPM 5, il motore di esecuzione dei processi del framework Activiti pu essere usato come ambiente di esecuzione standalone ed integrato come libreria in un progetto Java, oppure pu essere eseguito come servizio. La caratteristica principale del motore Activiti riguarda la separazione dei vari servizi applicati al motore di esecuzione; tutti i dettagli per linterazione con le API del motore Activiti sono disponibili nella documentazione ufficiale online.

Core Engine
Il motore di esecuzione del framework Activiti composto di almeno 2 livelli: il Process virtual machine, corrispondente al core engine, che fornisce un semplice modello per gli stati (attivit) e le transizioni, ed il motore, che fornisce le interfacce per interagire con il motore ed implementa la specifica BPMN 2.0. Il motore di esecuzione di Activiti pu essere configurato attraverso luso delle API pubbliche oppure impostando i parametri in un file di configurazione in un progetto Maven Java. Questo secondo metodo risulta utile quando devono essere impostati parseListener al motore di esecuzione. Nel motore di esecuzione di Activiti, molti degli elementi della specifica BPMN 2.0 sono implementati come stati o activity. Questi elementi sono collegati attraverso transizioni in partenza ed in arrivo, chiamati sequence flows in OMG BPMN 2.0. Ogni stato o il corrispondente elemento BPMN pu essere associato ad una procedura logica, che viene eseguita quando listanza del processo entra nello stato. La Figura 13 descrive in modo schematico limplementazione degli elementi activity nel motore di esecuzione del framework Activiti.

http://www.activiti.org

[ 35 ]

Parent 1 Nested states * Leaving Transitions State Arriving Transitions behaviour 1 Logic * * Transitions

Figura 13 - Struttura logica degli elementi Activity

Parser BPMN 2.0

Il parser corrisponde ad un componente del motore di esecuzione dei processi di Activiti; la funzione del parser riguarda la validazione dei file che contengono la definizione dei processi, in base al modello semantico della specifica BPMN 2.0. Le principali classi che definiscono la struttura del parser sono BpmnParser, BpmnParse e linterfaccia BpmnParseListener. Il process engine contiene una unica istanza della classe BpmnParser; attraverso BpmnParser possibile impostare i parseListeners e creare nuove istanze della classe BpmnParse.

Parser -INSTANCE : Parser +createParse() : Parse 1 BpmnParser -parseListeners : BpmnParseListener +createParse() : BpmnParse

interface Parse +execute() BpmnParse -parseListeners : BpmnParseListener +execute() 1

interface BpmnParseListener +parseProcess(in processElement : Element, in processDefinition) +parseServiceTask(in serviceTaskElement : Element, in scope, in activity : ActivityImpl) Element -uri : string -tagName : string -attributeMap -elements : Element ActivityImpl -outgoingTransitions -incomingTransitions -activityBehavior

Figura 14 - Parser motore Activiti, diagramma delle classi

[ 36 ]

Gli parseListeners corrispondono a validatori personalizzati della definizione di processo, con i quali possibile validare ed estrarre dati e parametri (non risolti dal default parser) a partire dal documento che contiene la definizione del processo; gli parseListener possono essere impostati attraverso il file di configurazione in un progetto Maven Java. Le istanze della classe BpmnParse sono usate per effettuare la validazione del documento .bpmn20.xml che contiene la definizione del workflow. In Figura 14 riportato il diagramma delle classi del parser di Activiti in cui ogni classe ed interfaccia presenta solo i principali attributi e metodi.

Modello Semantico della specifica BPMN 2.0

Il BPMN 2.0 metamodel inserito nel core engine di Activiti nella directory di progetto Activiti-Engine/src/main/resources/org/activiti/impl/bpmn/parser/. Il modello semantico viene usato dal motore di esecuzione durante la fase di validazione del documento XML che contiene la definizione del workflow. Il motore Activiti applica una limitazione importante alla modalit di estensione della specifica BPMN 2.0. Non infatti possibile inserire elementi figli diretti dellelemento process in uno XML Schema Extension Definition Document con target namespace differente dal namespace relativo la specifica BPMN 2.0. Questa caratteristica dovuta al metodo di parsing dei documenti .bpmn20.xml che contengono la definizione dei workflow. La classe BpmnParse infatti ha costruttore definito a livello package, questo significa che questa classe non pu essere estesa per poter gestire estensioni inserite con uno namespace differente.

Loop Activity
Il framework Activiti ha gi implementato gli elementi Loop Activity e gli elementi Multiple Instances Activity, per i nodi Task e Sub-Process.

Service Task
Il motore Activiti permette di associare uno handler ad un elemento Service Task attraverso lattributo estensione activiti:class; a differenza del motore jBPM 5, lassociazione elemento - handler non deve essere implementata nel motore di esecuzione prima di eseguire una istanza del workflow.

[ 37 ]

Lo handler di esecuzione della procedura una classe che implementa linterfaccia JavaDelegate oppure linterfaccia ActivityBehavior. Una classe che implementa linterfaccia JavaDelegate permette di avere accesso ad una istanza della classe DelegateExecution; una classe che implementa linterfaccia ActivityBehavior ottiene accesso ad una istanza della classe ActivityExecution. La classe ActivityExecution abilita una gestione attiva sul processo, ad esempio influenzando il flusso di controllo del processo stesso. Attraverso il parametro DelegateExecution del metodo execute, lo handler ha completa visibilit sullintero processo, quindi pu accedere a qualsiasi Property o DataObject globali. Spesso preferibile limitare la visibilit del Service Task alle sole variabili ed associazioni definite nella interfaccia. Il motore Activiti tuttavia non ha implementato la gestione dei campi InputOutputAssociation per gli elementi Service Task, perci non possibile associare direttamente una variabile di processo ad una variabile definita nella interfaccia; inoltre lo handler non ha la possibilit di accedere alle variabili definite nella interfaccia dellelemento ServiceTask. In aggiunta, la visibilit dello handler, tramite il parametro DelegateExecution, limitato allelemento process, questo significa che tutti gli elementi esterni allelemento process non sono accessibili; un caso di particolare interesse riguarda gli elementi itemDefinition: non essendo questi accessibili, non possibile conoscere il tipo di dato associato alle variabili di processo che fanno uso della propriet itemSubjectRef.

Analisi di una estensione dellelemento Service Task

A partire dalle considerazioni della sezione precedente, le caratteristiche che devono essere implementate nellelemento Service Task sono: 1. Associazione dei dati nella definizione della interfaccia 2. Gestione dei tipi di dato per gli elementi della interfaccia Relativamente il primo punto, la gestione degli elementi della interfaccia del Service Task deve avvenire durante lesecuzione del processo, in particolare prima della esecuzione dello handler associato allelemento Service Task. Activiti ha predisposto la possibilit di eseguire una procedura o funzione in determinati stati di esecuzione di una Activity; questa estensione, chiamata Execution Listener, tuttavia viene inserita allinterno di un elemento extensionElements nella

[ 38 ]

definizione del workflow (maggiori dettagli nella documentazione online); questa non certo la migliore soluzione per garantire la portabilit del workflow. Una soluzione alternativa prevede la registrazione dellExecution Listener del Service Task in fase di parsing della definizione del workflow. In particolare, il riferimento alla procedura che implementa linterfaccia ExecutionListener dovr essere associato alla definizione dellelemento ServiceTask allinterno del metodo parseServiceTask di una implementazione di BpmnParseListener. Lo Execution Listener permette di gestire lesecuzione del nodo Service Task, tuttavia non ha accesso alla definizione dellelemento; il custom parse listener usato in precedenza ottempera a questa richiesta andando ad acquisire gli elementi DataInput e DataOutput dalla interfaccia dellelemento Service Task e creando le associazioni con le variabili globali, definite nellelemento associations, attraverso linserimento di Property nellelemento Service Task. Allo stesso tempo vengono inserite opportune Property allelemento ServiceTask che permettono di associare ogni DataInput e DataOutput al relativo data type; il tipo di dato pu essere dichiarato esplicitamente oppure definito come riferimento ad elementi itemDefinition.

Definizione delle Service Task Properties legate alle Interface Associations Definizione delle Service Task Properties legate alle DataInput e DataOutput data types

Service Task Definition

Parse Listener

Custom Parse Listener

Service Task Start Execution Listener Registrazione degli Service Task Execution Listeners Service Task End Execution Listener

Crea le Service Task local variables pari alle DataInput e DataOutput Interface variables Assegnamento valori alle variabili globali in base alle Interface Associations

Workflow Execution

Service Task Instance

Service Task Execution

Figura 15 - Schema concettuale della estensione del Service Task

Dovranno quindi essere creati due Execution Listener: lo Service Task Start Execution Listener, attivato quando il flusso di esecuzione entra nellelemento ServiceTask ed il Service Task End Execution Listener, attivato alluscita dal ServiceTask.

[ 39 ]

Il Service Task Start Execution Listener deve creare le variabili locali al contesto di esecuzione del Service Task con nome e tipo di dato pari agli elementi DataInput e DataOutput definiti nella interfaccia dellelemento; inoltre, alle variabili locali relative gli elementi DataInput viene assegnato il valore delle corrispondenti variabili globali, in base alla associazione definita nelle opportune Property dellelemento ServiceTask. Lo Service Task End Execution Listener invece dovr assegnare alle variabili globali il valore delle variabili locali relative gli elementi DataOutput definiti nella interfaccia del ServiceTask. In Figura 15 viene riportato lo schema relativo lanalisi della soluzione. Le estensioni presentate in questo capitolo, relative lelemento Service Task, saranno riprese nel Capitolo 6 per la realizzazione di una definizione di workflow per il motore Activiti ed il confronto delle prestazioni con il motore jBPM 5.

[ 40 ]

Capitolo 6

Confronto motori BPMN 2.0

Il confronto dei motori di esecuzione jBPM 5 ed Activiti verr affrontato dal punto di vista della applicabilit di specifiche estensioni ai motori (estensibilit del modello semantico ed estensibilit delle funzionalit applicate agli elementi), e dal punto di vista delle prestazioni di esecuzione su uno stesso modello di workflow, applicando le estensioni opportune ai motori di esecuzione.

Applicabilit delle estensioni

Di seguito viene proposta una tabella riassuntiva relativa lapplicabilit delle estensioni al modello semantico per i motori jBPM 5 ed Activiti, le caratteristiche implementate e le relative estensioni per alcuni elementi della specifica BPMN 2.0, affrontate nei capitoli precedenti. jBPM 5 Modello semantico Estensione per addizione * Estensione per derivazione * Estensione per ridefinizione * Estensione con custom namespace applicabile applicabile non applicabile applicabile applicabile ** applicabile ** non applicabile applicabile Activiti

** Non applicabile per gli elementi figli dellelemento process, solo con default semantic module namespace. Elemento Service Task Gestione interfaccia Gestione tipi di dati gi definito gi definito estensione estensione

Loop Activity Elemento Service Task Elemento Sub Process da implementare estensione gi definito gi definito

[ 41 ]

jBPM 5 Multiple Instances Activity Elemento Service Task Elemento Sub Process da implementare gi definito

Activiti

gi definito gi definito

Confronto delle prestazioni

Il confronto dei motori di esecuzione per i framework jBPM 5 ed Activiti viene affrontato con lesecuzione di una definizione di processo il pi possibile simile per i due motori. Si scelto di effettuare il confronto su ambienti di esecuzione standalone, quindi i motori di esecuzione sono inseriti come librerie in progetti Java; inoltre lesecuzione dei workflow locale su una singola macchina. Machine Charactericstics Processor Model Cpu frequency Operating System Memory Engines Release Dual Core AMD Opteron 280 2.4 GHz Ubuntu Linux 10.10 x64 10 GB jBPM 5.2.0 Activiti 5.7 Java Version VM options JDK SE 7u2 -Xms256m -Xmx1g -Xss500m

I motori di esecuzione sono eseguiti con configurazione di default; per il motore jBPM 5 stato inoltre configurato il Knowledge Base per gestire un nuovo namespace ed il relativo modello semantico inserito come estensione (vedi Capitolo 4); per il motore Activiti stata usata la configurazione StandaloneProcessEngineConfiguration, inoltre i servizi JobExecutor ed History sono attivati durante lavvio del motore.

Parametri di valutazione
I parametri di valutazione delle prestazioni nella esecuzione dei workflow implementati nei motori di esecuzione includono: Corretta terminazione della esecuzione dei singoli nodi e del processo (affidabilit) Velocit di esecuzione del workflow (simili parametri ed ambiente di esecuzione)

Relativamente la velocit di completamento dello handler di esecuzione per gli elementi Service Task, necessario garantire prestazioni simili per entrambi i motori di [ 42 ]

esecuzione; le prestazioni della esecuzione dei servizi esterni al flusso di esecuzione del workflow possono dipendere infatti dalla Java Virtual Machine su cui vengono eseguiti e dallarchitettura di calcolo.

Algoritmo Welded Beam Design

Il workflow usato per confrontare le prestazioni dei motori riguarda la simulazione di una particolare ottimizzazione del problema Welded beam design; questo un problema di ottimizzazione multi-obiettivo, che coinvolge due funzioni obiettivo e sette vincoli. La formalizzazione del problema di ottimizzazione descritta in (Pham & Ghanbarzadeh, 2007). Il problema Welded Beam design si occupa della progettazione di una mensola saldata, con lobiettivo di minimizzare il costo di realizzazione e di minimizzare la flessione della trave, caricata allestremit libera. La configurazione dei parametri di progetto per il problema Welded beam design mostrata in Figura 16. I parametri di ingresso sono dati dallo spessore del cordone di saldatura h (weld thickness), la lunghezza del cordone di saldatura l (weld lenght), la larghezza della trave t (beam thickness) e laltezza della trave b (beam width).

Figura 16 - Welded Beam

Le funzioni obiettivo del problema di ottimizzazione riguardano la minimizzazione dei costi di fabbricazione e la minimizzazione del valore beam deflection per combinazioni ammissibili dei parametri weld thickness h, weld length l, beam thickness t e beam width b. Nella valutazione delle prestazioni dei motori BPMN 2.0 siamo interessati a studiare la fase di simulazione del modello di workflow; le fasi di pianificazione del problema di ottimizzazione e post-processing non vengono quindi affrontate in modo specifico. [ 43 ]

La procedura di simulazione dellalgoritmo Welded Beam design viene affidata alla applicazione Open Source di computazione numerica Scilab; il workflow usato per la simulazione dovr eseguire Scilab come servizio in background, e la simulazione dovr essere effettuata ad ogni ciclo di esecuzione per una data combinazione dei parametri in ingresso. Il codice dello script Scilab che implementa la valutazione della simulazione per il problema Welded Beam design sui parametri di ingresso (h,l,t,b) stato acquisito da (LIONSolver, Use Case Welded beam design). Lalgoritmo fornisce in output il valore dei costi di fabbricazione, il valore beam deflection, ed il valore della funzione penalty function, usata nei problemi di ottimizzazione multi obiettivo per esprimere attraverso un valore numerico la violazione dei vincoli sui valori di uscita. Il modello di workflow stato semplificato riducendo il numero di variabili in ingresso al problema. Usando come riferimento i vincoli sui parametri di ingresso proposti in (Pham & Ghanbarzadeh, 2007) e le osservazioni in fase di post-processing riguardo la dipendenza fra i parametri di ingresso (LIONSolver, Use Case Welded beam design), possibile definire un nuovo insieme di vincoli sui parametri di ingresso:

(1)

{
Una prima simulazione dellalgoritmo Welded beam design e lo studio della distribuzione della penalty function, calcolata per ognuna delle combinazioni dei parametri di ingresso ( 1 ), ha permesso di osservare come le soluzioni ammissibili al problema (con valore penalty function pari a zero) siano concentrate per valori dei parametri . Le simulazioni usate per il confronto fra i motori di esecuzione jBPM 5

ed Activiti sono state effettuate considerando questo secondo dominio.

Modello di Workflow per il problema Welded beam design

Il modello di workflow (Figura 17) contiene 6 elementi DataObject: i parametri h e b del problema Welded beam design, le variabili nValB e loopValB, usate per definire il dominio triangolare sulle variabili h e b, la variabile InstanceCounter che viene usata come contatore sul numero di istanze dellelemento Sub-Process ed il valore nrOfInstances che contiene il numero totale di cicli del sottoprocesso. Il workflow costituito da un elemento Loop Activity Sub-Process, in cui gli elementi Data Input del sottoprocesso sono tutte le variabili del processo principale; ad ogni [ 44 ]

istanza del ciclo, il sottoprocesso aggiorna i valori degli elementi DataObject del processo principale. Lelemento Sub-Process contiene un elemento Service Task, usato per eseguire la simulazione sui parametri di ingresso. Lo handler di esecuzione dellelemento Service Task deve eseguire diverse operazioni: 1. Acquisizione dei valori delle variabili definite nella interfaccia. 2. Aggiornamento delle variabili di processo in base al passo ed il dominio triangolare dei parametri h e b. 3. Inserimento delle variabili di processo InstanceCounter, h e b in un file di testo, usato nella esecuzione dello script Scilab per acquisire i parametri di input. 4. Esecuzione di uno script bash shell per la simulazione dello script Scilab sui parametri di ingresso; i risultati di ogni esecuzione dello script Scilab vengono inseriti in un opportuno file di testo. 5. Acquisizione e stampa a video dei risultati della esecuzione dello script Scilab. Mentre la rappresentazione del modello di workflow risulta essere uguale per entrambi i motori di esecuzione jBPM 5 ed Activiti, il documento XML che definisce il modello di workflow deve essere adeguato ai singoli motori di esecuzione nel rispetto della validit del modello e la gestione delle rispettive estensioni.

nValB

loopValB

InstanceCounter nrOfInstances

InstanceCounter < nrOfInstances

Figura 17 - Modello di workflow per il problema Welded beam design

Nella valutazione delle prestazioni dei due motori di esecuzione, dovr essere verificato il comportamento delle estensioni applicate ai motori di esecuzione, in [ 45 ]

particolare lelemento Loop Activity Sub-Process per il motore jBPM 5 e la gestione della interfaccia per lelemento Service Task nel motore Activiti.

Risultati
Lesecuzione del workflow per i motori jBPM 5 ed Activiti con un numero crescente di istanze per lelemento Loop Activity Sub-Process ha portato ai seguenti risultati: Il workflow viene eseguito e termina in modo corretto in entrambi i motori di esecuzione per ognuno dei valori della variabile di input nrOfInstances. Il tempo di esecuzione del workflow per i motori di esecuzione si distribuisce come rappresentato in Figura 18. Si pu osservare come il tempo di esecuzione per il motore Activiti sia notevolmente maggiore rispetto il tempo di esecuzione per il motore jBPM 5 con laumentare del numero di istanze. Questo test non permette tuttavia di capire se questo risultato sia dovuto alla differenza di prestazioni fra i due motori di esecuzione oppure alla procedura dello handler di esecuzione del nodo Service Task.

32 30 28 26 24 22 20 18 16 14 12 10 8 6 4 2 0 1000 5000 10000 25000 50000 75000 numero di istanze

tempo di esecuzione (ore)

Activiti jBPM5

Figura 18 - Tempo di esecuzione del workflow per il problema Welded beam design

Un secondo test di esecuzione del workflow ha permesso di verificare che il maggiore tempo di esecuzione del workflow nel primo test per il motore Activiti dovuto principalmente alla procedura dello handler di esecuzione per lelemento Service Task. Rispetto il test precedente, il secondo test non esegue la procedura dello handler di esecuzione per il nodo Service Task, isolando in tal modo lesecuzione del workflow e limplementazione delle estensioni applicate agli elementi del workflow. [ 46 ]

Il tempo di esecuzione del workflow rappresentato in Figura 19. Si pu osservare come il tempo di esecuzione per il motore Activiti sia ancora maggiore del tempo di esecuzione per il motore jBPM 5 con laumentare del numero di istanze per il nodo Loop Activity Sub-Process. La notevole differenza di prestazioni del primo test tuttavia non imputabile tanto al processo di esecuzione del motore Activiti, quanto alla gestione della esecuzione della procedura nello handler di esecuzione per il nodo Service Task nelle Java Virtual Machine.

1.800 1.680 1.560 1.440 1.320 1.200 1.080 960 840 720 600 480 360 240 120 0 1000 5000 10000 25000 50000 75000 numero di istanze

tempo di esecuzione (secondi)

Activiti jBPM5

Figura 19 - Tempo di esecuzione del workflow per il problema Welded beam design (secondo test)

[ 47 ]

Conclusioni

Lo sviluppo dei sistemi di controllo per workflow scientifici a partire dai sistemi di controllo per business workflow ha acquisito notevole interesse con lintroduzione della specifica BPMN 2.0; la formalizzazione del modello semantico definisce uno standard per la modellizzazione, la gestione e lesecuzione di ogni componente del workflow. I sistemi di controllo per workflow scientifici vengono estesi a partire dai sistemi di controllo per business workflow con linserimento di nuovi nodi di elaborazione e specifiche funzionalit, spesso associate alla gestione dei nuovi elementi inseriti. Nella prima parte del lavoro di tesi sono state studiate le estensioni applicabili al modello semantico della specifica BPMN 2.0, attraverso alcuni costrutti della specifica XML Schema. Nei Capitoli 4 e 5 sono state quindi valutate le implementazioni delle estensioni al modello semantico per i motori di esecuzione jBPM 5 ed Activiti. Le implementazioni delle estensioni al modello semantico per entrambi i motori di esecuzione risultano essere sufficienti per linserimento di nuovi elementi ed attributi agli elementi standard della specifica BPMN 2.0. Il motore jBPM 5, a differenza del motore Activiti, permette inoltre di inserire elementi figli dellelemento process con prefisso e namespace differente da quelli forniti dal BPMN 2.0 metamodel. Nella seconda parte del lavoro di tesi sono stati implementati due motori di esecuzione per sistemi di controllo per workflow scientifici, a partire dai motori di esecuzione per business workflow jBPM 5 ed Activiti. Le funzionalit implementate nei motori di esecuzione sono state elaborate come estensione delle funzionalit di elementi standard della specifica BPMN 2.0. Le estensioni implementate riguardano: gestione dellelemento Service Task (inserito come estensione dellelemento Service Task della specifica BPMN 2.0, con custom namespace) e gestione dellelemento Loop Activity Sub-Process, per il motore jBPM 5, inoltre gestione della interfaccia e tipi di dati per lelemento Service Task, nel motore Activiti. Le nuove funzionalit dei motori di esecuzione sono risultate essere stabili, mentre le prestazioni di esecuzione di una stessa definizione di workflow per i due motori di esecuzione, ha evidenziato un peggioramento delle prestazioni del motore Activiti rispetto il motore jBPM 5 con laumentare del numero di istanze nel workflow. [ 48 ]

Sviluppi futuri potranno affrontare il confronto dei motori di esecuzione per linserimento e la gestione di ulteriori elementi nella definizione dei workflow scientifici, quale ad esempio il nodo DataStore; pu essere utile inoltre il confronto dei diversi metodi di sviluppo dei sistemi di controllo per workflow scientifici, per quanto riguarda la gestione del flusso dati nel workflow e le prestazioni di esecuzione dei singoli componenti.

[ 49 ]

Bibliografia
Allweyer, T. (2009). BPMN 2.0 Introduction to the Standard for Business Process Modeling (2nd ed.). Norderstedt: Books on Demand GmbH. Clarich, A., & Russo, R. (2011). Use Of Multi-variate-data-analysis, fast algorithms and grid automation in modeFRONTIER for multi-objective optimization. ECCOMAS Thematic Conference - CFD & OPTIMIZATION 2011 - 006. Antalya TURKEY. Deb, K. (2011). Multi-Objective Optimization using Evolutionary Algorithms. John Wiley & Sons Ltd. Lin, C., & al. (2009). A Reference Achitecture for Scientific Workflow Management Systems and the View SOA Solution. IEEE Transactions on Services Computing 2, 79-92. LIONSolver. (Use Case Welded beam design). Welded beam design (structural steel engineering): how to tradeoff multiple objectives. Retrieved from Reactive Search: http://www.lionsolver.com/info/cases/multiple_objectives_optimization/ OMG. (2011). Business Process Modeling and Notation, v.2.0. Retrieved from OMG Available Specification, OMG Document Number: formal/2011-01-03: http://www.omg.org/spec/BPMN/2.0/PDF Pham, D., & Ghanbarzadeh, A. (2007). Multi-Objective Optimisation using the Bees Algorithm. Network. Shapiro, R., & al. (2010). BPMN 2.0 Handbook. Future Strategies Inc. Walmsley, P. (2001). Definitive XML Schema. Prentice Hall PTR. WfMC. (1995, January). The Workflow Reference Model. WFMC-TC-1003, Version 1.1. Retrieved from Workflow Management Coalition: http://www.wfmc.org/standards/docs/tc003v11.pdf

[ 50 ]

Ringraziamenti

Dedicato a Marta, aspirante scienziata

Il primo ringraziamento rivolto allazienda Esteco S.p.A.

un ringraziamento in particolare al gruppo Research and Development

Ringrazio inoltre il professore Eric Medvet

Ringraziamento speciale rivolto alla mia famiglia

Infine, doveroso un ringraziamento a Dario