Processi Distribuiti
Di
Brusadelli Alessio 666663
Brivio Marco 666662
Indice
Indice .................................................................................................................................................. 1
Introduzione ..................................................................................................................................... 2
Processi Distribuiti.......................................................................................................................... 3
Il modello dei dati ............................................................................................................................ 4
Modellazione di interazioni basate su messaggi ....................................................................... 6
“Click4ALoan” .................................................................................................................................... 7
Distribuzione dei workflow in “Click4ALoan” ............................................................................ 9
Scenario 1: Distribuzione semplice .......................................................................................... 9
Scenario 2: Distribuzione di un singolo servizio ................................................................. 10
Scenario 3: Distribuzione dei sotto-processi ..................................................................... 11
Distribuzione con controllo centralizzato........................................................................ 14
Distribuzione con controllo distribuito ............................................................................ 16
Progettazione dell’ipertesto ........................................................................................................ 20
1
Introduzione
Tutti i modelli web (e le relative rappresentazioni tramite site view) che abbiamo
finora studiato, si basavano implicitamente sull’assunzione che i vari attori del sistema
interagissero con un unico database centrale, unico repository dei meta-dati del
processo, il quale codificava in modo indipendente dall’applicazione le interazioni con il
sistema e i relativi flussi di navigazione.
Ora verrà rimossa tale assunzione e si discuterà di processi distribuiti, processi le cui
attività possono essere eseguite su server (peer) differenti, i quali perciò non
condividono alcuno spazio di memoria (repository di meta-dati).
Introduciamo ora diversi termini che saranno ricorrenti in questo contesto e con i
quali sarà importante familiarizzare:
1. Processo: rappresenta l’insieme delle azioni che intendiamo svolgere per
raggiungere un dato obiettivo. Una istanza di processo, nota come case, è una
singola attivazione del processo. Un processo può avere diversi stati: attivo,
completo, sospeso, terminato, archiviato.
2. Attività: è un passo elementare all’interno di un processo. Un’istanza di attività
è una singola invocazione di una attività, in un dato case. Un’ attività può avere
diversi stati: attiva, inattiva, completa, sospesa, terminata, archiviata.
2
Processi Distribuiti
La Distribuzione dei Processi è quel processo di design dell’applicazione mediante il
quale vengono assegnate le diverse attività, che compongono l’intero processo da
modellizzare, a vari server che possono eseguirle.
Le Attività sono unità atomiche di distribuzione, cioè dato un compito che può essere
suddiviso in varie sotto attività, esso deve essere scisso in attività più piccole da far
eseguire ciascuna a server differenti. La composizione di tutte queste sotto attività
(e del loro flusso di esecuzione), le quali lavorano su differenti host di diverse
organizzazioni, rappresenta l’intero Processo che si è voluto modellizzare.
Da un punto di vista tecnologico, il fatto di coinvolgere diverse organizzazioni, pone il
problema della diversità dei dati tra di esse, e il problema di poter effettuare queries
e update trasparenti sui vari database di organizzazioni diverse.
Per questo motivo, ogni organizzazione fornisce dei servizi web (meglio noti come Web
Services) mediante i quali l’utente remoto può accedere ai dati locali di una
organizzazione, e poterli modificare secondo una logica definita, per evitare errori
generici nel flusso delle operazioni da eseguire e per fornire sicurezza all’accesso ai
dati. Inoltre, essendo i nodi coinvolti nel processo interagenti tra di essi via http,
nasce la necessità di poter comunicare tramite questo protocollo, e di pubblicare
ipertesti e Web Services accessibili via http, nonché di utilizzare i database locali o
trasparentemente distribuiti per poter memorizzare i dati dell’applicazione e del
processo in atto.
Sotto queste ipotesi, per poter governare correttamente i processi distribuiti,
bisogna estendere l’approccio visto finora con:
1. Un modello che ci permetta di esprimere i requisiti di distribuzione, e per far
ciò utilizzeremo la notazione BPMN, che ci permetterà di assegnare
esplicitamente varie attività a diversi nodi coinvolti nel processo.
2. Integrare la distribuzione nel modello ipertestuale. Per far ciò verranno
introdotte alcune nuove primitive (unit) che ci consentiranno di pubblicare e
invocare servizi remoti, nonché di gestire il relativo flusso di lavoro tra i vari
peer.
Per poter descrivere meglio questo approccio utilizzeremo un caso di studio, che ci
fornisce un esempio semplice ma espressivo dell’utilizzo di queste tecnologie e ci
permetterà di comprendere con più chiarezza i vari contenuti.
3
Il modello dei dati
Per poter gestire processi distribuiti tramite workflow, bisogna utilizzare un
particolare modello dei dati che ci permetta di poter utilizzare al meglio le nozioni di
Attività e Processo e di poter mappare al meglio le relative relazioni. La figura 1 ci
mostra il modello E-R che viene utilizzato per utilizzare efficientemente un workflow.
[Figura 1: Meta-modello dei dati per il Workflow]
Come possiamo notare il database è diviso in 3 aree principali: l’area evidenziata in blu
rappresenta il modello dei dati che permette di rappresentare l’accesso degli utenti a
site view protette e la loro appartenenza a gruppi. L’area evidenziata in verde
corrisponde alla porzione del database che viene utilizzata per modellizzare i dati
della nostra applicazione, mentre l’area evidenziata in rosso è il modello dei dati che si
utilizza durante un workflow. Esso è composto da varie entità che ci garantiscono un
corretto funzionamento di tutto il processo:
PROCESS: Contiene la descrizione del processo utilizzato dall’applicazione, ed è
caratterizzato da: Nome, Descrizione, ID.
4
CASE: Memorizza le istanze di processi attivati durante l‘esecuzione dell’applicazione,
ed è caratterizzato da: Nome, Started, Ended.
CASE STATUS: Memorizza lo stato delle istanze del processo attivato durante
l‘esecuzione dell’applicazione, ed è caratterizzato da: Nome che può essere:Active,
Complete, Suspended, Terminated, Archived.
ACTIVITY: Memorizza la descrizione dei tipi di attività che compongono un processo,
ed è caratterizzato da: Nome, Descrizione, ID.
ACTIVITY ISTANCE: Memorizza le istanze delle attività attivate durante
l‘esecuzione dell’applicazione, ed è caratterizzato da: Started, Ended.
ACTIVITY ISTANCE STATUS: Memorizza lo stato delle istanze delle attività
attivate durante l‘esecuzione dell’applicazione, ed è caratterizzato da: Nome che può
essere: Active, Inactive, Complete, Suspended, Terminated, Archived.
Come possiamo notare i dati relativi alla nostra applicazione sono relazionati con la
parte di database relativa al workflow tramite le istanze dell’attività con cardinalità
0:N. Infatti una applicazione può avere da 0 a N istanze di attività, mentre le istanze
di attività sono relazionate con 0:N applicazioni.
5
Modellazione di interazioni basate su messaggi
Anche a livello di ipertesto si è sentita la necessità di poter modellare le interazioni
tra i vari server permettendo una comunicazione semplice tra di essi, tramite la
creazione e l’utilizzo di messaggi in uscita, la ricezione e il relativo processare dei
messaggi in ingresso. A questo scopo WebML ha introdotto varie units che
permettono di modellare i principali scenari di interazione tra Web Services esistenti.
I concetti base sono stati incapsulati in operation units dedicate, chiamate Web
Service units, che rappresentano i principali tipi di messaggi scambiati nelle
comunicazioni intra-server.
Queste units, come mostrato in figura 2, corrispondono alle primitive offerte da
WSDL: request-respons, solicit-response, one-way e notification.
[Figura 2: WebML Web Service units]
Si adotta una convenzione grafica per poter spiegare le varie tipologie di interazione:
le interazioni che coinvolgono due messaggi (request-respons e solicit-response) sono
rappresentati con una freccia curva, mentre frecce da sinistra a destra implicano
l’utilizzo di messaggi di input dalla prospettiva del servizio (es. messaggi inviati
dall’applicazione Web al service provider).
Inoltre, a seconda del protocollo di comunicazione utilizzato, le operazioni di requestrespons e solicit-response possono essere definite come operazioni sincrone o
asincrone. Nel caso asincrono il processo lato richiedente non è sospeso in attesa della
risposta e può proseguire nell’interazione con l’applicazione Web, e il messaggio sarà
recapitato in un secondo momento. Queste unit vengono rappresentate secondo la
notazione WebML divise in due metà, come mostrato in figura 2. Questa divisione
rappresenta il fatto che i due messaggi non sono direttamente correlati: il link
uscente dalla metà superiore rappresenta la sequenza di operazioni eseguite
dall’applicazione dopo che è stato ricevuto il messaggio asincrono.
Nel caso sincrono, invece, il processo richiedente si blocca in attesa di una risposta.
6
“Click4ALoan”
L’esempio che volevamo presentare è relativo ad un workflow per la gestione dei
prestiti bancari via web. Innanzitutto possiamo identificare tre diversi attori che
prendono parte al processo di richiesta/gestione del prestito: l’utente che richiede il
prestito, il manager che effettua una validazione preliminare e una valutazione finale,
e gli impiegati, che hanno il compito di verificare che l’utente abbia tutti i requisiti
necessari per poter ricevere il finanziamento desiderato (Job Check e Financial
Check). Il flusso di operazioni che si intende seguire è rappresentato il figura 3.
In azzurro sono rappresentatele operazioni effettuate dall’ utente (APPLICANT), in
arancio quelle svolte dal manager aziendale (MGR) e in rosa quelle svolte dagli
impiegati (EMPL).
Il processo rappresenta i passi necessari per poter effettuare la richiesta di un
prestito bancario. Il processo inizia con la richiesta di un utente. Tale richiesta arriva
al manager aziendale che ne fa una valutazione preliminare e decide se i dati immessi
sono non validi, interrompendo così tutto il processo, oppure se sono validi; in questo
caso il processo procederebbe e il manager passerebbe la richiesta agli impiegati.
A questo punto il processo si divide in due parti che possono essere svolte in
disgiunzione: infatti se l’utente avesse fatto richiesta di un prestito semplice, l’unica
verifica da effettuare da parte degli impiegati è quella finanziaria, mentre nel caso di
un mutuo, essi devono verificare sia lo stato finanziario dell’utente, sia effettuare una
verifica sull’impiego dell’utente. Una volta effettuate tali verifiche, la richiesta
ritorna nelle mani del manager, che effettua una verifica finale e decide se accettare
o meno la richiesta di prestito, proponendo al cliente, in caso positivo, una serie di
offerte/proposte tra le quali scegliere. A questo punto l’utente decide se accettare
una di queste proposte o rifiutare il prestito, terminando così tutto il processo.
7
[Figura 3: Workflow di “Click4ALoan”]
8
Distribuzione dei workflow in “Click4ALoan”
Scenario 1: Distribuzione semplice
Caso base di utilizzo dei workflow.
Non c’è distribuzione: tutti i passi del processo vengono svolti sullo stesso peer, e con
lo stesso database condiviso. In figura 4 possiamo notare il flusso di processo
dell’applicazione “Clkick4ALoan”, che viene svolto tutto sul peer B.
[Figura 4: Visione globale del processo di richiesta di un prestito]
9
Scenario 2: Distribuzione di un singolo servizio
Il flusso di processo viene svolto sostanzialmente sullo stesso peer, ma a differenza
della distribuzione semplice sono presenti contatti con peer diversi tramite l’utilizzo
di web services, invocati per ottenere dati da database remoti.
[Figura 5: Distribuzione semplice di un singolo servizio]
10
Scenario 3: Distribuzione dei sotto-processi
Con la distribuzione dei sotto processi, il processo che finora veniva svolto sullo
stesso peer, viene ora spezzato in sotto attività da dover delegare a diversi peer,
introducendo così diversi overhead di sincronizzazione delle attività, nonché di
coordinazione delle attività tra i diversi peer.
La distribuzione dei sotto processi aggiunge una nuova dimensione all'attività di
design: la scelta di dove perfezionare il controllo del processo distribuito.
Il progettista deve scegliere quale peer si prenderà cura di maneggiare l'evoluzione
delle attivià del processo a runtime. In principio, la gestione del processo può essere
delegata ad alcuni sottoinsiemi dei peer coinvolti. In particolare, identifichiamo due
scelte principali: controllo di processo centralizzato (con utilizzo di web services che
manovrano il processo intero), e controllo di processo distribuito (con utilizzo di web
services diversi che dividono la gestione del processo).
In figura 6 possiamo vedere come sono state suddivise le varie sotto-attività in
diversi peer: il peer principale (peer B) delega infatti al peer A diverse attività, tra le
quali Financial Check, Residence Check e Credit Check, ma si preoccupa di portare a
termine l’intero processo di richiesta del prestito.
11
[Figura 6: Visione globale della distribuzione dei processi]
12
Esistono diverse tipologie di distribuzione dei sotto-processi:
Distribuzione con controllo centralizzato
Distribuzione con controllo distribuito
o Controllo distribuito annidato
o Controllo distribuito generale
13
Distribuzione con controllo centralizzato
Nella prima tipologia il processo principale (centralizzato, peer B) ha il controllo totale
dell’ avanzamento dello stato delle operazioni e dei processi dopo che è stata svolta
ogni attività del workflow.
In figura 7 possiamo osservare un sequence diagram che rappresenta l’interazione tra
tre peer differenti in un contesto di processo distribuito con controllo centralizzato.
Le linee verticali denotano l’evoluzione temporale delle attività ed ogni numero
corrisponde all’esecuzione di una attività. Nell’esempio possiamo vedere come il
coordinatore (Peer B) esegue l’attività 1 e delega la 2 al peer A, che appena ha
terminato la sua esecuzione contatta il coordinatore con un messaggio di
completamento. Questa procedura avviene per tutte le attività svolte da ogni peer.
[Figura 7: Controllo di Processo centralizzato]
La figura 8 mostra invece l’intero flusso di processo nel caso di controllo
centralizzato: per ogni attività svolta nel peer A, vengono pubblicate in un web service
tutte le informazioni relative a tale attività e vengono utilizzate dal processo
principale per mantenere uno stato consistente di tutto il processo. Inoltre, durante
queste fasi, il processo centralizzato governa tutte le sotto-attività tramite l’utilizzo
di start/end activity e di assign unit, sempre con l’obiettivo di mantenere lo stato
globale di avanzamento del processo.
14
[Figura 8: Processo distribuito con controllo centralizzato]
15
Distribuzione con controllo distribuito
Nella distribuzione con controllo di processo distribuito, nessun sotto sistema
coinvolto è sempre consapevole dello stato completo del processo. In questo caso il
peer principale, è distinto come quello che inizia il processo. Tipicamente, il peer che
inizia il processo lo completa anche, ma tale simmetria non è obbligatoria per il
controllo del processo distribuito. Alcuni peer possono compiere uno o più attività,
senza il bisogno di notificare agli altri peer sullo stato di avanzamento delle
operazioni. Inoltre, ogni peer che esegue uno o più attività può delegare nuove attività
agli altri peer.
Questo comporta che i meta-dati di processo sono distribuiti sui vari peer, ed la
traccia di avanzamento delle attività (ad esempio, la ricerca dello status corrente di
un caso) può richiedere la consultazione di tutti i peer coinvolti.
Il Controllo del processo distribuito richiede la coordinazione dei vari peer, i quali
governano l'evoluzione delle sotto-attività.
La Coordinazione dei peer consiste nella comunicazione delle attività distribuite, così
da garantire che l’avanzamento del processo proceda secondo i vincoli di esecuzione
specificati nel modello di processo. La Coordinazione di peer può seguire dei modelli di
cui riconosciamo due varianti principali: coordinazione annidata e generalizzata.
Coordinazione annidata
La Coordinazione annidata consiste della possibilità per un peer di delegare un sottoprocesso "ben-parentesizzato"
ad un altro peer; un sotto-processo " benparentesizzato " è un processo in cui, nella rappresentazione BPMN, si mette in
mostra un solo punto di entrata e un solo punto di uscita.
Fondamentalmente, i sotto-processi che possono essere annidati sono quelli che
possono essere considerati come sequenza di attività indipendenti strutturate
internamente in una gerarchia di sotto-attività.
Nella figura 9 possiamo osservare tale comportamento: solo dopo l’esecuzione delle
attività 2, 3 e 4 il Peer B viene a conoscenza dello svolgimento di tutte le sotto
attività svolte sul peer A.
16
Main Peer
Peer A
Peer B
1
2
3
4
5
6
[Figura 9: Coordinazione annidata]
In figura 10 possiamo osservare un processo distribuito con coordinazione annidata,
nel quale possiamo notare i sotto-processi "ben-parentesizzati", caratterizzati da un
unico punto di ingresso/uscita tra i vari peer. In questa configurazione non è possibile,
da parte del peer B, tener traccia dello stato di tutte le sotto-attività svolte al peer
A, ma verrà a conoscenza dei risultati solo alla fine dell’esecuzione di tutte queste
sotto-attività.
17
[Figura 10: Processo distribuito con coordinazione annidata]
18
Inoltre, tener traccia dello stato di un processo in una coordinazione annidata è come
tener traccia dello stato in un processo gerarchico: ogni peer può mantenere le
informazioni sulle attività locali che lo coinvolgono, e può tenere traccia localmente di
tutte le informazioni del sotto-processo. Queste informazioni sono viste come un
black box, in quanto il peer conosce lo stato (inactive/active/completed) del sottoprocesso, ma ignora i dettagli di tale sotto-processo. Nel caso in cui si voglia accedere
a tali informazioni è necessaria effettuare una query “gerarchica”, che deve essere
passata tra i peer che formano la gerarchia.
Coordinazione generalizzata
Con la coordinazione generalizzata, qualsiasi sottoinsieme delle attività componenti il
processo possono essere delegate ad altri peer, senza tener conto di particolari
vincoli. In questo caso non è possibile identificare un singolo punto di accesso/uscita
dal processo delegato al peer remoto.
Con la coordinazione generalizzata sono richiesti diversi messaggi per poter ottenere
un corretto avanzamento in presenza di sotto-processi delegati ad altri peer. Per
questo motivo, per ogni freccia di flusso tra diversi peer, deve essere scambiato un
messaggio, e il numero di queste frecce può essere molto maggiore di due, in quanto
non c’è necessità di una buona parentesizzazione.
19
Progettazione dell’ipertesto
La progettazione dell’ipertesto è influenzata notevolmente dalla distribuzione del
processo, perché le applicazioni Web devono essere suddivise fra i vari peer coinvolti,
seguendo il modello di interazione progettato in precedenza.
Dato che i meta-dati di processo non possono essere globalmente disponibili in un
database centrale ed unico, devono essere scambiati vari messaggi per permettere
l’interazione ai vari peer, come abbiamo visto negli scenari precedenti.
In questo contesto, lo scambio di messaggi può essere modellizzato utilizzando le
primitive di Web Service fornite da WebML, le quali si integrano perfettamente a
modelli di ipertesto.
In seguito, riporteremo delle viste di ipertesti che modellano il processo di richiesta
di un prestito dell’applicazione “Click 4a Loan”. Come possiamo notare dalla seguente
figura seguente sul “peer A” avviene la richiesta di prestito, la relativa “Start
Activity” del processo e la compilazione dei dati da parte del richiedente. A questo
punto viene creata una nuova istanza di Applicazione e viene chiamato un Web Service
remoto a cui vengono passati tutti i dati dell’applicazione/attività corrente. Il servizio
richiamato viene svolto sul peer B, dove avviene la validazione preliminare da parte del
manager.
[Figura 11: Frammento di ipertesto per la richiesta di un prestito (peer A)
e per la validazione preliminare (peer B)]
20
Nella figura 12, invece, possiamo notare l’ipertesto che permette la validazione
preliminare da parte del manager, svolta al “peer B”. Essa abilita l’attività di Financial
Check svolta localmente, e comunica il risultato della validazione al peer A. Questo
passaggio è fondamentale nel processo in quanto le due sotto attività di Job e
Financial Check sono svolte su due peer differenti, e perciò al momento della ricezione
al peer A dello stato delle attività, esso effettuerà una update dello stato
dell’applicazione, assegnando ad essa le attività di Job Check. Questo procedimento di
divisione delle attività sui due peer permette di avere entrambe le attività in AND,
non permettendo perciò di proseguire se la seconda attività non è stata completata.
[Figura 12: Frammento di ipertesto per la validazione preliminare (peer B)]
Infine la figura 13 mostra l’ipertesto che ci permette di effettuare il Financial Check
(al peer B) e il Job Check (al peer A). Oltre all’esecuzione delle attività canoniche, il
peer B effettua una chiamata a Web Service per notificare al peer A il
completamento dell’attività. Il peer A, alla ricezione della richiesta, effettua le
valutazione necessarie a implementare il processo, e ritorna una notifica al peer B.
Inoltre la stessa valutazione è effettuata per l’attività di Job Check.
21
[Figura 13: Frammento di ipertesto per il Financial e il Job Check]
A conclusione di tutto questo discorso vogliamo notare come gli ipertesti che
implementano processi distribuiti sono progettati nella stessa maniera di quelli
centralizzati, e le uniche differenze riscontrabili sono:
La suddivisione delle site view in locali e remote. La parte locale modella
l’interfaccia di ipertesto offerta dal peer per poter effettuare tutte le
interazioni con gli altri peer, la parte remota modella le azioni eseguite dai peer
remoti quali ricezione di notifiche di messaggi e ricezione dello stato di
avanzamento dei processi.
La presenza di Web Service che modellano le comunicazioni dell’avanzamento
dei processi ai vari peer.
22
La modellazione di processi distribuiti con la notazione BPMN, con il modello di
iperteso esteso, con le unit per i Web Service e i Workflow, permette al progettista
di esprimere ogni schema e ogni politica di distribuzione in un modo concettuale,
accompagnato dalla possibilità di evoluzioni future e dalla generazione automatica del
codice.
23
