Cos’è un Workflow?
Cercare di dare una definizione formale di Workflow non è propriamente banale visto che il concetto di workflow può essere associato a significati anche molto differenti.
Nella figura che segue si compara il grado di maturità dell’hype tecnologico di un Workflow rispetto al ben più consolidato e “stagionato” Relational Database Management Systems (vedere [TSOW]).

Figura 1: Hype curve: Workflow Vs RDBMS

Si può definire un Workflow come l’automazione di un processo di business, in tutto o solo in parte, durante il quale i documenti, le informazioni o i compiti sono passati da un partecipante a un altro per compiere una determinata azione secondo quanto specificato da un insieme di regole procedurali ben definite.
Un workflow costituisce quindi un flusso di lavoro composto da un insieme di attività correlate tra loro attraverso diverse tipologie di relazioni.

Figura 2: Un esempio di workflow di gestione di un ordine

Gli attori di un Workflow
Un workflow è la definizione formale di un processo, utilizzata per la gestione di particolari attività (gestione di ordini, pubblicazione di articoli, etc.). Tutti i workflow sono sistemi orientati al processo.
La definizione di un processo rappresenta ciò che deve accadere all’interno del sistema durante un processo di business o una procedura e può essere composta da un insieme di sotto-processi. Ciascun processo e sotto-processo è composto, a sua volta, da un insieme di attività. Ogni attività è un singolo step logico all’interno del processo.
Un workflow esegue attività automatiche; la definizione di un processo, invece, descrive tutte le attività sia automatiche sia manuali.
La definizione di un processo (cosa debba essere fatto, in che ordine e da chi) viene formalizzata in termini di:

• Stato (nodo): Uno stato all’interno di un processo specifica una dipendenza rispetto ad un attore esterno. A runtime questo comporta che il motore di workflow deve attendere fino a quando un attore esterno notifica che l’esecuzione è stata portata a termine.
  
• Azione: Un’azione è la logica applicativa che deve essere eseguita dal motore di workflow in seguito al presentarsi di un evento specifico. I flussi di esecuzione concorrenti sono modellati con fork e join, mentre i flussi di esecuzione esclusivi sono modellati con merge e punti di decisione.
  
• Transizioni: rappresentano lo spostamento del processo da uno stato ad un altro attraverso l’applicazione di una predeterminata azione.
  
• Process Context: è il contesto del processo gestito dal workflow.
  

La figura che segue (vedere [JBPM4]) riassume l’anatomia di un processo:

Figura 3: Anatomia di un processo

Il Workflow Management System
Definito il concetto di workflow, vediamo di definire che cosa è un sistema di Workflow Management (WFMS) .
Un Workflow Management System è un sistema che permette di definire, creare e gestire l’esecuzione di workflow attraverso l’utilizzo di software in esecuzione all’interno di uno o più motori di workflow. Un workflow manager si occupa di interpretare la definizione formale (ricevuta come input) di un processo, scritta con un linguaggio standard (es: XML, BPEL) o proprietario (es: jPdl), al fine di interagire con i vari attori partecipanti gestendone lo stato ed il coordinamento delle attività.

Da un punto di vista pratico, un WFMS è un componente software che prende in input la descrizione formale del processo di business e mantiene lo stato di esecuzione delegando le attività alle applicazioni e/o persone necessarie al completamento dello stesso.

Mentre la definizione di processo (process definition) è la descrizione formale del processo (stati, transizioni, variabili di contesto, attività associate, …) un’istanza di processo è l’istanza concreta di un processo attualmente in esecuzione.
Paragonando quanto detto all’OOP, il process definition è analogo alla classe mentre un’istanza di processo è il corrispettivo di un oggetto istanza della classe stessa.

Figura 4: Analogia Classe / Definizione di Processo

Il processo, a sua volta, è composto da step che il processo “attraversa”. Di fatto, durante l’esecuzione di un processo, il sistema di gestione del motore di workflow utilizza un token per tenere traccia dello stato corrente. Questo token è corrispondente al concetto di “program counter” all’interno delle macchine di Von Neumann. Quando il token arriva in uno stato particolare viene assegnato ad un attore esterno che può essere un utente, un gruppo o un sistema.
Compito del WFMS è di mantenere correlato all’istanza del processo le informazioni specifiche del suo contesto (context information). Ogni istanza di processo, quindi, avrà un proprio contesto. Al Process Context possono essere associate una o più variabili (process context variable).
Generalmente le variabili del contesto del processo sono dichiarate nella definizione del processo stesso e sono inizializzate all’atto della creazione del processo da parte del WFMS.
Il processo può transitare attraverso più stati che possono essere di diversi tipi. Durante l’esecuzione del processo possono essere associate una o piu’ azioni. Le azioni sono porzioni di logica applicativa che devono essere eseguite dal WFMS in seguito a un ben preciso evento.
Da un punto di vista terminologico è bene evitare di usare un generico termine di attività (activity) ma differenziare in modo preciso tra stato (state) e azione(action) (vedere [TSOW]).

Un semplice esempio di Workflow
Vediamo ora di esemplificare quanto è stato precedentemente spiegato.

Figura 5: Esempi di Workflow Pattern

Nel nostro esempio ci focalizzeremo su due semplici pattern (per approfondire i pattern legati ai workflow è possibile consultare [WPAT]):
Sequence: un’attività all’interno del workflow è eseguita solo in seguito alla terminazione dell’attività precedente.
Exclusive choiche: all’interno del workflow esiste un punto in cui si decide di seguire un percorso piuttosto che un altro basandosi su quanto presente nel contesto di esecuzione.
L’esempio considerato mostra un sistema di gestione degli ordini. In particolare, alla ricezione di un ordine viene verificato il credito di un cliente, se il credito è sufficiente l’ordine viene evaso altrimenti viene scartato.

Figura 6: Il processo d’esempio

Per implementare tale esempio utilizzeremo tre differenti motori di workflow: OSWorkflow di Open Symphony, JBPM di JBoss e Oracle BPEL Process Manager. I tre motori si riferiscono rispettivamente ai seguenti ambiti di workflow: workflow (in senso “stretto” del termine), Business Process Management(BPM) e orchestration.

Anche se non è possibile dare definizioni di workflow, BPM e orchestration ampiamente accettate, è comunque possibile fare alcune considerazioni al riguardo (vedere [JBPM2]).
Caratteristiche comuni a queste tre tipologie di sistemi è il prevedere la definizione formale di un processo e la possibilità di avere stati di attesa durante l’esecuzione dei processi nonostante i diversi ambiti applicativi. Infatti, mentre i workflow sono solitamente correllati alla gestione di attività svolte dalle persone, il Business Process Management (BPM) combina l’utilizzo di workflow con l’integrazione di applicazioni Enterprise (EAI) mentre l’Orchestration è prettamente orientato alla “orchestrazione” dei Web Services.

Figura 7: Workflow, BPM & Orchestration

Open Symphony – OSWorkflow
OSWorkflow (vedere [OS]) è un motore di workflow open source e può essere considerato come un’implementazione di “basso livello”. Situazioni come cicli di loop o condizioni che, in altri motori di workflow, possono essere espressi attraverso un’opportuna rappresentazione grafica devono essere codificati in OSWorkflow utilizzando un linguaggio di scripting. OSWorkflow si basa ampiamente sul concetto di macchina a stati finiti. Ciascuno stato rappresenta la combinazione di un identificatore e di uno stato. Una transizione tra uno stato e un altro può avvenire anche senza alcuna azione esterna.
Al cuore di OSWorkflow vi è il descrittore di definizione del workflow. Questo descrittore è un file XML. Il descrittore contiene tutti gli step, gli stati, le transizioni e le funzionalità per un dato workflow.
Il file XML può essere creato manualmente oppure utilizzando l’editor grafico di OSWorkflow.

Figura 8: Diagramma degli stati in OsWorkflow

L’utilizzo del designer di OSWorkflow facilita la creazione del descrittore XML che, altrimenti, deve essere effettuata manualmente.
Ad esempio, il file XML corrispondente al workflow indicato è:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE workflow PUBLIC "-//OpenSymphony Group//DTD OSWorkflow 2.7//EN" "http://www.opensymphony.com/osworkflow/workflow_2_7.dtd">
<workflow>
<initial-actions>
<action id="1" name="Start Workflow">
<restrict-to>
</restrict-to>
<pre-functions>
<function type="class">
<arg name="class.name">it.mokabyte.mokaworkflow.ReceiveOrderPreFunction</arg>
<arg name="orderNumber">${orderNumber}</arg>
</function>
</pre-functions>
<results>
<unconditional-result id="3" old-status="Finished" status="OrderNotReceived" step="1"/>
</results>
</action>
</initial-actions>
<steps>
<step id="1" name="ReceiveOrder">
<actions>
<action id="2" name="Receive Order">
<restrict-to>
</restrict-to>
<results>
<unconditional-result id="4" old-status="OrderNotReceived" status="OrderReceived" step="2"/>
</results>
</action>
</actions>
</step>
<step id="2" name="CheckOrder">
<actions>
<action id="3" name="Check Order">
<restrict-to>
</restrict-to>
<results>
<result id="6" old-status="OrderReceived" status="OrderChecked" step="3">
<conditions>
<condition name="CheckOrder" type="class">
<arg name="class.name">it.mokabyte.mokaworkflow.CheckOrderCondition</arg>
<arg name="creditCardNumber">${creditCardNumber}</arg>
</condition>
</conditions>
</result>
<unconditional-result id="5" old-status="OrderReceived" status="OrderDenied" step="4"/>
</results>
</action>
</actions>
</step>
<step id="3" name="PerformOrder">
<actions>
<action id="4" name="Perform Order">
<restrict-to>
<conditions>
<condition name="Verifica autorizzazione OK" type="class">
<arg name="class.name">
com.opensymphony.workflow.util.StatusCondition
</arg>
<arg name="status">OrderChecked</arg>
</condition>
</conditions>
</restrict-to>
<results>
<unconditional-result id="1" old-status="OrderChecked" status="OrderPerformed" step="5"/>
</results>
</action>
</actions>
……
</steps>
</workflow>

In corrispondenza di ciascuno stato viene eseguita una determinata azione (primo o dopo la transizione di stato può essere eseguita quella che OSWorkflow definisce con il nome di function). L’azione che deve essere eseguita è determinata da una condition. OSWorkflow esegue la prima action per cui la condition è verificata. Se non è verificata alcuna condizione, viene eseguita un’ azione di default che deve essere sempre specificata.
Le condition sono implementate da classi Java che implementano l’interfaccia com.opensymphony.workflow.Condition mentre le function, invece, sono implementate da classi Java che implementano l’interfaccia com.opensymphony.workflow.FunctionProvider.
A secondo della tipologia di elemento da inserire nel workflow è necessario implementare l’opportuna interfaccia.
Un esempio di condition è riportato nel seguito:

public class CheckOrderCondition implements Condition {
  public boolean passesCondition(Map transientVars, Map args, PropertySet ps)
    throws WorkflowException {
      Logica della condition: il valore di ritorno deve essere true o false
  }
}

Per quanto riguarda, invece, una function:

public class CheckOrderPreFunction implements FunctionProvider {
  public void execute(Map transientVars, Map args, PropertySet ps) {
  logica applicativa dell’action
  }
}

JBoss JBPM
JBoss JBPM è il motore di workflow open source proposto da JBoss (vedere[JBPM]).
I processi di jBPM sono creati utilizzando un linguaggio proprietario di definizione dei processi di nome jPdl. La gestione dello stato con jBpm si basa su un grafico con nodi e transizioni che costituiscono la definizione di un processo. Le interazioni principali con jBpm sono due: avviare l’esecuzione di un processo e segnalare la terminazione di uno stato. In entrambi i casi jBpm si occupa di calcolare lo stato successivo.
Il grafico degli stati fornisce la struttura del processo. Le azioni sono costituite da logica applicativa (classi che implementano l’interfaccia org.jbpm.graph.def.ActionHandler) che può essere eseguita in seguito a eventi particolari come l’ingresso in un nodo, l’uscita da un nodo e la transizione di stato. Le definizioni dei processi sono contenute all’interno di file XML che possono essere costruiti “a mano” o mediante il tool grafico JBoss jBPM Graphical Process Designer distribuito come plugin di eclipse. In modalità grafica “drag-and-drop” è quindi possibile disegnare facilmente il nostro processo di esempio.

Figura 9: Design del workflow di esempio mediante il tool JBPM

Il design del processo corrisponde alla creazione automatica del file XML dei definizone del processo da parte del tool.

Figura 10: Il file XML di definizone del processo

La creazione degli Handler (action) da associare agli eventi di interesse è costituita da una classe Java che deve implementare l’interfaccia org.jbpm.graph.def.ActionHandler:

import org.jbpm.graph.def.ActionHandler;
public class MokaActionHandler implements ActionHandler {
  public void execute(ExecutionContext executionContext) throws Exception {
    // Logica applicativa dell’Action
    . . . .
    context.getContextInstance().setVariable("message", “Hello World!”);
    . . . .
    context.leaveNode("tr2");
    . . . .
  }
}

Oracle BPEL
L’Oracle BPEL Designer (vedere [ORA_BPD] ) permette di definire in modo grafico i processi ed ottenere la generazione automatica del codice secondo lo standard BPEL.
Con il tool è quindi possibile, in modalità grafica “drag-and-drop” (Design View), disegnare facilmente il processo di esempio ed ottenere la generazione automatica del corrisponde codice BPEL (Source View)

Figura 11: Oracle BPEL Designer: BPEL4WS Design View e Source View

Conclusioni
In questo articolo abbiamo introdotto i concetti fondamentali legati ai Workflow ed un semplice esempio pratico.
Per ulteriori approfondimenti sull’argomento si rimanda alla bibliografia.

Bibliografia
[TSOW] The state of workflow - http://www.jbpm.org/state.of.workflow.html
[WPAT] W.M.P. van der Aalst1, A.H.M. ter Hofstede, B. Kiepuszewski,A.P. Barros: Workfow Patterns - http://is.tm.tue.nl/research/patterns/download/wfs-pat-2002.pdf
[WPAT2] Workfow Patterns - http://www.openwfe.org/docbook/build/ch07.html
[WPAT3] http://is.tm.tue.nl/research/patterns/
[OSWFMS] Open Source Workflow Engines Written in Java: http://www.manageability.org/blog/stuff/workflow_in_java/view
[JBPM] JBoss Process Manager: http://www.jbpm.org/
[JBPM2] http://jbpm.org/3/introduction.html
[JBPM_GPD] JBoss jBPM GPD: Getting Started : How to create your first process definition: http://jbpm.org/gpd/index.html
[JBPM3]J. Koenig: Integrating Business Process Management with Open Source JBoss jBPM
http://www.jboss.com/pdf/jbpm_whitepaper.pdf
[JBPM4] T. Baeyens: jBpm: Open Source Solution for BPM
http://erp.ittoolbox.com/documents/document.asp?i=1888
[OS] Open Simphony - http://www.opensymphony.com/
[ORA_BPM] Oracle BPEL Process Manager:
http://www.oracle.com/technology/products/ias/bpel/index.html
[ORA_BPM2] Oracle BPEL Process Manager download:
http://www.oracle.com/technology/software/index.html
[WFRM] Workflow Reference Model Diagram -http://www.wfmc.org/standards/model.htm