Thesis full text PDF - Politecnico di Milano

POLITECNICO DI MILANO
FACOLTA’ DI INGEGNERIA DELL’INFORMAZIONE
SEDE DI MILANO LEONARDO
DIPARTIMENTO DI ELETTRONICA E INFORMAZIONE
CORSO DI LAUREA SPECIALISTICA IN INGEGNERIA INFORMATICA
Modellazione concettuale di processi
aziendali distribuiti basati su
architettura Web Services
Relatore:
Correlatore:
Prof. Ceri Stefano
Ing. Brambilla Marco
Tesi di laurea di:
Brivio Marco 666662
Brusadelli Alessio 666663
ANNO ACCADEMICO 2004-2005

Indice
1. Introduzione ................................................................................................... 1
2. Workflow ........................................................................................................ 5
2.1. Concetti ...................................................................................................... 7
2.2. Notazioni .................................................................................................. 10
2.3. Casi di studio ............................................................................................ 13
2.3.1. Click4aLoan ........................................................................................ 13
2.3.2. Click4aCar .......................................................................................... 15
3. Web Service .................................................................................................. 17
3.1. Coreografia e orchestrazione ....................................................................... 20
4. WebML .......................................................................................................... 23
4.1. Modello dei dati ......................................................................................... 25
4.2. Modello di ipertesto .................................................................................... 26
4.2.1 Site-view............................................................................................. 27
4.2.2 Pagine ................................................................................................ 27
4.2.3 Unit .................................................................................................... 27
4.2.4 Operation ............................................................................................ 29
4.2.5 Link .................................................................................................... 30
4.2.6 Parametri globali .................................................................................. 31
4.3. Modello di presentazione ............................................................................. 31
4.4. Estensione di WebML per i Workflow ............................................................. 32
4.4.1. Modello di processo ............................................................................. 32
4.4.2. Modello dei dati ................................................................................... 32
4.4.3. Modello di ipertesto ............................................................................. 34
4.5. Estensione di WebML per i Web Service ......................................................... 36
4.5.1. Primitive per la descrizione e la pubblicazione di servizi ............................. 36
4.5.2. Primitive per l’invocazione di servizi ....................................................... 40
5. Workflow Distribuiti ..................................................................................... 42
5.1. Distribuzione di un singolo servizio ............................................................... 44
5.2. Distribuzione dei sotto-processi .................................................................... 46
5.2.1. Distribuzione con controllo centralizzato ................................................. 46
5.2.2. Distribuzione con controllo distribuito ..................................................... 49
5.2.2.1. Controllo distribuito con coordinazione annidata ................................ 49
5.2.2.2. Controllo distribuito con coordinazione generalizzata .......................... 52

5.3. Interazione fra processi indipendenti ............................................................. 54
5.4. Stili di progettazione .................................................................................. 58
5.4.1. Automatico vs. Manuale ....................................................................... 58
5.4.2. Push vs. Pull ....................................................................................... 59
5.4.3. Assegnamento delle attività .................................................................. 60
5.4.4. Scenari .............................................................................................. 60
5.4.5. Gestione dei meta-dati ......................................................................... 62
6. Progettazione delle applicazioni ................................................................... 65
6.1. Click4aLoan ............................................................................................... 66
6.1.1. Requisiti ............................................................................................. 67
6.1.2. Modello dei dati ................................................................................... 69
6.1.3. Ipertesto ............................................................................................ 74
6.1.3.1. Organizzazione delle site-view ........................................................ 74
6.1.3.2. Implementazione degli scenari di distribuzione .................................. 76
6.2. Click4aCar .............................................................................................. 101
6.2.1. Requisiti ........................................................................................... 101
6.2.2. Modello dei dati ................................................................................. 103
6.2.3. Ipertesto .......................................................................................... 104
6.2.3.1. Organizzazione delle site-view ...................................................... 104
6.2.3.2. Implementazione degli scenari di distribuzione ................................ 104
7. Related Work .............................................................................................. 114
8. Conclusioni ................................................................................................. 118
Bibliografia ..................................................................................................... 122

Introduzione Capitolo 1
1. Introduzione
1

Introduzione Capitolo 1
A partire dalla metà degli anni novanta lo sviluppo massiccio di sistemi informativi in rete e delle
tecnologie Internet ha stimolato l’interesse di svariate discipline nei confronti dei meccanismi di
gestione di processi interaziendali.
In particolare i mercati della “new economy” hanno contribuito alla generazione di nuove tecniche
di gestione di flussi di processo che si pongono come veri e propri elementi innovativi rispetto ai
meccanismi tradizionali.
Inoltre, la crescente complessità delle attività all’interno delle organizzazioni, porta la pianificazione
e la gestione di processi e risorse a diventare un elemento critico nella gestione organizzativa.
La concomitanza dei fattori sopra esposti ha portato a sottolineare alcune peculiarità tipiche dei
workflow distribuiti, sviluppati e progettati attraverso tecnologie informatiche:
- I mezzi elettronici possono aiutare a dare una rappresentazione formale del problema della
gestione del processo, supportando gli attori nella loro attività.
- Il numero dei potenziali interlocutori che partecipano al processo può aumentare,
permettendo diversi scenari di interazione tra i partecipanti.
- Le tecnologie informatiche possono meglio supportare i responsabili nella pianificazione e
nella realizzazione di processi più strutturati, in particolare è molto più facile avere a
disposizione dati storici sulle interazioni precedenti al fine di scegliere le migliori strategie
per la conduzione dell’attività corrente.
- L’introduzione di standard per lo studio, la realizzazione e la gestione di processi distribuiti,
ha reso possibile una maggiore comprensibilità dei lavori esistenti ed ha portato ad una
visione unitaria dei problemi.
L’insieme di tutti questi aspetti innovativi ha stimolato la ricerca scientifica verso tecniche di
gestione di processi aziendali sempre più avanzate, ovvero verso la creazione di applicazioni
software in grado di gestire in maniera organizzata le attività componenti i processi aziendali.
L’utilizzo di applicazioni a supporto della gestione dei processi aziendali fornisce notevoli vantaggi,
specialmente nel caso in cui essi sono svolti in diverse località remote che necessitano di essere
interfacciate in real time:
- Riduce il tempo di negoziazione, in quanto l’interazione fra attori umani è relativamente
lenta.
- Rimuove la reticenza degli umani nell’occuparsi di processi di questa natura.
- Permette di ottenere comunicazioni di business con partecipanti in differenti zone orarie.
2

Introduzione Capitolo 1
Alla luce di tutto ciò, il lavoro proposto vuole focalizzarsi sullo studio e sulla realizzazione di
applicazioni web che permettano l’esecuzione di attività facenti parte di un processo aziendale
distribuito geograficamente su diversi server.
La distribuzione geografica dei processi introduce diverse difficoltà di comunicazione in quanto i
dati remoti devono essere resi disponibili nel minor tempo possibile dai vari server, in modo che il
processo aziendale non subisca ritardi dovuti alla mancanza di dati. Per poterla concretizzare,
utilizzeremo la tecnologia dei Web Service a supporto dei workflow per garantire lo scambio di dati
tra diversi server, sui quali risiedono frammenti del flusso di processo aziendale, i quali perciò
necessitano di una coordinazione.
Per poter ottenere tali risultati utilizzeremo il linguaggio concettuale Web Modeling Language [7]
(WebML) per la specifica e la progettazione di applicazioni data-intensive, che propone una
notazione per la specifica, la progettazione e la pubblicazione automatica di siti web a partire da
specifiche di alto livello. In una delle sue estensioni, WebML permette la realizzazione di siti web
che permettono l’esecuzione e la gestione di flussi di processo. Tutto questo si pone ad un livello di
design più basso rispetto alla progettazione classica di un processo di business, in quanto il flusso
di processo viene integrato all’interno della progettazione dell’applicazione web e non ad un livello
di astrazione più elevato.
Obiettivo del nostro lavoro è quello di analizzare i vari scenari esistenti nella gestione di workflow
distribuiti, di realizzare tali scenari con dei prototipi mediante casi di studio e di analizzare come
WebML reagisce alle varie casistiche che il problema pone.
Il nostro lavoro si pone come un elemento innovativo se si considera che, allo stato attuale, i
principali tool presenti sul mercato permettono la realizzazione di applicazioni web residenti su un
singolo server, e che si propone di realizzare applicazioni aziendali che partano da un modello di
processo preesistente e che permetta di distribuire parti di questo processo su server differenti.
Dal punto di vista implementativo sono state realizzate quattro applicazioni Web (più le rispettive
varianti) che hanno permesso di coprire tutti gli scenari possibili in un contesto distribuito. Queste
applicazioni sono state realizzate tramite l’ausilio di un tool sviluppato al Politecnico di Milano,
WebRatio ® [26], che ci ha permesso, utilizzando le notazioni introdotte da WebML, l’impiego delle
tecnologie dei Web Service a supporto della gestione di flussi di processi distribuiti.
Il lavoro si presenta suddiviso in capitoli, di cui forniamo una breve descrizione:
3

Introduzione Capitolo 1
Il capitolo 2 offre una panoramica generale sui workflow, introducendo concetti di stampo teorico,
viene introdotta una notazione grafica per rappresentare flussi di processo, e vengono presentati i
casi di studio implementati nei progetti.
Il capitolo 3 delinea un quadro completo e preciso dei Web Service, introducendone concetti e
notazioni attualmente adottate.
Il capitolo 4 si concentra sulla descrizione del linguaggio di modellazione WebML, e in particolare
sulle sue estensioni per poter utilizzare le tecnologie dei workflow e dei Web Service.
Il capitolo 5 fornisce una visione esaustiva degli scenari individuati nel mondo dei workflow
distribuiti, e la loro applicazione ai casi di studio trattati.
Il capitolo 6 presenta la progettazione delle applicazioni che implementano gli scenari presentati nel
capitolo 5 e la relativa modellazione WebML, corredata da esempi di implementazione per fornire
una panoramica sull’esperienza implementativa maturata durante lo svolgimento dei progetti.
Il capitolo 7 presenta un’analisi di lavori esistenti e relazionati al nostro ambito di studio.
Il capitolo 8 conclude il lavoro proposto riportando osservazioni e considerazioni sul lavoro svolto e
un’analisi critica delle tecnologie utilizzate.
4

Workflow Capitolo 2
2. Workflow
5

Workflow Capitolo 2
In accordo con il modello di riferimento proposto dalla Workflow Management Coalition [27], un
workflow si preoccupa di automatizzare procedure in cui documenti, informazioni o tasks vengono
passati fra i vari attori, rispettando definiti set di regole per poter ottenere o contribuire ad un
obiettivo comune. Più semplicemente può essere descritto come l’agevolazione o
l’automatizzazione computerizzata di un processo di business, in parte o totalmente. Se da un lato,
un flusso di processo potrebbe essere organizzato manualmente, nella pratica è normalmente
strutturato all’interno di un sistema IT per fornire un supporto automatizzato per l’automazione
procedurale.
L’automatizzazione di un processo di business è definita all’interno di una specifica di processo, in
cui si identificano le varie attività, le regole procedurali e i rispettivi dati di controllo, che vengono
utilizzati per gestire il workflow durante l’esecuzione del processo. Ogni istanza del processo ha
associato un set specifico di dati che sono rilevanti per quella determinata istanza di processo
(Case).
Una distinzione viene segnata tra workflow di produzione e workflow ad-hoc; i primi utilizzano
regole procedurali definite a priori, mentre nei secondi le regole procedurali possono essere
modificate o create durante le operazioni del processo.
Un sistema di gestione di workflow, o meglio “Workflow Management System”, è un sistema che
definisce, crea e gestisce l’esecuzione dei workflow attraverso l’utilizzo di software, i quali vengono
eseguiti su uno o più workflow engine, i quali sono in grado di interpretare le definizioni di
processo, interagire con i partecipanti e invocare l’uso di tool e applicazioni IT quando richiesto.
I vantaggi da esso apportati sono diversi:
- Il lavoro non va in stallo e non segue percorsi non corretti e perciò gli impiegati sono
raramente chiamati a recuperare situazioni di errore.
- I manager possono focalizzarsi su problemi di business quali performance individuali,
procedure di ottimizzazione, e casi speciali, anziché badare all’assegnamento delle attività.
Gli impiegati sono sollevati dal compito di inviare e tenere traccia del loro lavoro, in quanto
queste operazioni sono svolte in automatico.
- Le procedure sono documentate formalmente ed eseguite correttamente; ciò assicura che il
lavoro sia svolto nella maniera in cui è stato pianificato dal manager, andando a soddisfare
tutti i requisiti a cui è soggetto.
6

Workflow Capitolo 2
- I compiti più importanti vengono svolti per primi, assegnando la persona o macchina più
appropriata ad ogni attività componente il processo. Gli impiegati non sprecano tempo
scegliendo il lavoro da svolgere o rimandando compiti complessi ma al contempo
importanti.
- Viene migliorata l’efficienza in quanto l’automatizzazione dei processi porta all’eliminazione
di molti step non necessari.
- Rispetto ad un workflow tradizionale, l’introduzione del parallelismo, cioè l’esecuzione
concorrente di più task, porta ad una semplificazione del processo e a minor attese e
perdite di tempo.
- Porta miglioramenti anche per quanto riguarda il servizio clienti, in quanto la consistenza
del processo porta ad una maggiore prevedibilità del livello di risposta ai clienti.
- Dal punto di vista della flessibilità si hanno dei vantaggi in quanto il controllo
computerizzato dei processi permette la loro riprogettazione in linea con i cambiamenti di
business richiesti.
Tutti questi vantaggi fanno si che l’utilizzo dei workflow porti benefici sia all’azienda che esegue i
processi in maniera più efficiente con minor costo, sia agli impiegati che sono portati ad eseguire
sempre il lavoro corretto.
2.1. Concetti
Scopo di questa sezione è quello di identificare i concetti di base e la terminologia [1] associata ai
workflow.
• Business process: insieme di una o più procedure o attività collegate, le quali realizzano
collettivamente un obiettivo comune, normalmente all’interno del contesto di una struttura
organizzativa che definisce ruoli funzionali e relazioni.
Un business process può coinvolgere interazioni formali o informali tra i partecipanti e la
sua durata può variare largamente.
Può essere composto da attività automatizzate in grado di gestire il workflow e/o da attività
manuali le quali non riguardano ciò che concerne la gestione del workflow.
7

Workflow Capitolo 2
• Process: rappresentazione di un processo di business in una forma che supporta la
manipolazione automatica. La definizione di un processo consiste in una rete di attività e
nelle loro relazioni, criterio atto ad indicare l’avvio, la terminazione di un processo, le
informazioni legati alle attività individuali, i partecipanti, le applicazioni associate, i dati,
ecc…
La definizione di un processo può contenere collegamenti a sottoprocessi, definiti
separatamente, che possono prendere parte alla definizione globale di processo.
• Process Instance (Case): rappresentazione di una singola istanza di processo, creata,
gestita ed eventualmente terminata da un workflow management system, in accordo con la
definizione di processo. Ogni process instance usa dati propri ed è in grado di procedere
indipendentemente attraverso i vari step fino al suo completamento o terminazione.
Ogni process instance mantiene uno stato interno che rappresenta il suo stato di
avanzamento attraverso le attività che la compongono.
Una process instance può trovarsi in vari stati:
- Initiated: l’istanza di processo è stata creata ma non è in esecuzione.
- Running: l’istanza di processo ha iniziato la sua esecuzione ed una o più delle sue
attività possono essere eseguite.
- Active: uno o più activity sono iniziate e sono state create delle activity instance.
- Suspended: l’istanza di processo è quiescente: ulteriori activity non possono essere
iniziate prima che essa riprenda la sua esecuzione.
- Completed: l’istanza di processo ha raggiunto le condizioni di terminazione.
- Terminated: l’esecuzione del processo è stata interrotta in maniera non corretta a
causa di errori o su richiesta dell’utente.
- Archived: l’istanza di processo è in uno stato di archiviazione, ma può essere riabilitata
per la ripresa del processo.
• Activity: descrizione di una parte di lavoro che forma uno step logico all’interno di un
processo. Un’attività può essere manuale, che non supporta automazione computerizzata, o
automatizzata. Un’attività di workflow richiede delle risorse umane o hardware per
supportare l’esecuzione del processo; quando è richiesta una risorsa umana, l’attività viene
assegnata ad un utente coinvolto nel workflow.
Un’attività è tipicamente la più piccola unità di lavoro che è schedulata da un workflow
engine durante l’esecuzione del processo.
8

Workflow Capitolo 2
• Activity Instance: rappresentazione di un’attività all’interno di una singola istanza di
processo. Ogni activity instance rappresenta una singola invocazione di una attività,
relazionata esattamente ad una istanza di processo, ed usa i dati associati all’istanza di
processo. Diverse activity instance possono essere associate ad un process instance, ma
un’activity instance non può essere associata a più process instance.
Un’activity instance può trovarsi in vari stati:
- Inactive: l’activity instance è stata creata, ma non ancora attivata; non esiste un workitem
per quella attività.
- Active: uno o più work-item sono stati creati e assegnati per essere processati.
- Suspended: l’activity instance è quiescente: ulteriori work-item non possono essere
iniziati prima che essa riprenda la sua esecuzione.
- Completed: l’activity instance ha raggiunto le condizioni di terminazione.
• Work-Item: rappresentazione del lavoro che deve essere processato nel contesto di
un’attività all’interno di un’istanza di processo. Un work-item è normalmente presentato
all’utente per mezzo di una lista di lavori, che mantiene i dettagli dei work-item assegnati a
quello specifico utente.
Dopo aver analizzato i concetti base dei workflow, vediamo come essi si relazionano fra loro
mediante lo scheda in figura:
Figura 1 - Relazioni tra la terminologia di base
9

Workflow Capitolo 2
2.2. Notazioni
Tra le varie notazioni nell’ambito dei workflow, presentiamo la Business Process Modeling Notation
(BPMN) [4], una notazione grafica per rappresentare flussi di processo, la quale verrà utilizzata in
seguito per descrivere i casi di studio trattati.
La Business Process Modeling Notation è uno standard sviluppato dalla Business Process Modeling
Initiative, con lo scopo di fornire una notazione chiara, completa e facilmente comprensibile da tutti
gli utenti, sia dagli analisti di business, sia dagli sviluppatori e sia da coloro che gestiranno e
monitoreranno i processi rappresentati, fornendo un ponte standardizzato che colma il gap tra la
progettazione dei processi di business e la loro implementazione.
La BPMN definisce un Business Process Diagram (BPD) che, utilizzando diagrammi di flusso
composti da un insieme di elementi grafici, permette la creazione di modelli di business process, e
allo stesso tempo di gestire in maniera efficace la complessità che essi comportano.
La BPMI nella definizione dello standard ha scelto di organizzare gli elementi grafici della notazione
in categorie specifiche, permettendo al lettore di riconoscere e capire facilmente gli elementi base
dei diagrammi. Le quattro categorie base di elementi sono: Flow Objects, Connecting Objects,
Swimlanes e Artifacts.
I Flow Objects sono i tre elementi base che compongono un Business Process Diagram: Event,
Activity e Gateway.
Event
Un evento è rappresentato da un cerchio ed è qualcosa che
accade durante il processo. Esistono tre tipi di eventi:
Start, Intermediate e End.
Gli eventi si possono rendere specifici al contesto di utilizzo
inserendo al loro interno vari simboli. Un esempio può
essere l’evento riguardante la ricezione di un messaggio.
Activity
Una attività è rappresentata da un rettangolo smussato e
rappresenta un compito da svolgere nel processo.
10

Workflow Capitolo 2
Gateway
Un gateway è usato per controllare la divisione o la
convergenza di flussi di lavoro ed è rappresentato da un
rombo con all’interno il simbolo che identifica il tipo di
controllo (es. “+” AND, “X” XOR).
I Connecting Objects permettono di connettere fra loro i Flow Objects per creare una
struttura schematica del processo. Sono stati definiti tre tipi di simboli:
Sequence
Flow
Usato per mostrare l’ordine in cui le attività devono essere
eseguite in un processo, e viene rappresentato da una
freccia semplice.
Message
Flow
Usato per mostrare il flusso di messaggi fra due
partecipanti del processo, e viene rappresentato da una
freccia tratteggiata.
Association
Usato per associare dati, testo e altri oggetti con i Flow
Objects e per mostrare gli input e gli output delle attività,
ed è rappresentato da una linea punteggiata.
Le Swimlanes sono un meccanismo che permette di organizzare le attività in categorie
visuali separate e di illustrare differenti capacità o responsabilità.
Pool
Rappresenta un partecipante di un processo
e agisce come contenitore grafico per
partizionare un set di attività da altri pool.
Lane
È una sottopartizione all’interno di un pool e
serve per organizzare e categorizzare
attività.
Gli Artifacts permettono di estendere la notazione fornendo elementi per descrivere in maniera più
dettagliata le diverse situazioni:
11

Workflow Capitolo 2
Data
Object
Sono meccanismi per mostrare come un dato è richiesto o
prodotto da una attività e sono connessi alle attività tramite
le association.
Group Il raggruppamento può essere usato per scopi di
documentazione o di analisi, ma non influisce sul flusso di
processo.
Annotation Sono dei meccanismi che forniscono informazioni
addizionali per il lettore del diagramma.
Uno degli utilizzi di BPMN è quello di realizzare diagrammi che descrivano l’interazione tra due o più
entità di business creando un modello di tipo collaborativo chiamato processo Business-to-Business
(B2B). Per questo motivo, nel nostro lavoro di tesi, adotteremo questa notazione per descrivere i
casi di studio trattati.
12

Workflow Capitolo 2
2.3. Casi di studio
In questo paragrafo introdurremo una descrizione dettagliata, utilizzando la notazione BPMN, dei
flussi di processo caratterizzanti i due casi di studio trattati, che ci serviranno per poter modellare e
implementare le diverse varianti di distribuzione dei flussi di processo individuate.
2.3.1. Click4aLoan
Il primo caso di studio è relativo ad un flusso di processo per la gestione di 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 (Applicant), il manager che effettua
una validazione preliminare e una valutazione finale, e gli impiegati (Employee), che hanno il
compito di verificare che l’utente abbia tutti i requisiti necessari per poter ricevere il finanziamento
desiderato tramite diverse attività di controllo (Job Check, Financial Check, Residence Check, Credit
Check).
Nella pagina successiva viene illustrato, tramite la notazione BPMN, il flusso di operazioni che
compongono il workflow di Click4aLoan.
Il processo rappresenta i passi necessari per poter effettuare la richiesta di un prestito bancario.
Esso inizia con la richiesta di un prestito da parte di un utente (Applicant). Tale richiesta viene
processata dapprima da un manager aziendale che ne fa una valutazione preliminare e verifica se i
dati immessi dall’utente sono validi, interrompendo, in caso contrario, l’intero processo. Nel caso in
cui i dati siano validi il processo proseguirebbe la sua esecuzione e il manager passerebbe la
richiesta agli impiegati, effettuando una selezione dei compiti da assegnare ad ogni impiegato.
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 (Loan), le verifiche da effettuare da parte
degli impiegati sono quella finanziaria, di residenza e di credito bancario. Nel caso di un mutuo
(Mortgage), invece, gli impiegati devono verificare sia lo stato finanziario dell’utente e la residenza,
sia effettuare una verifica sull’impiego dell’utente. Una volta effettuate tali verifiche, la richiesta
ritorna sotto la competenza del manager, che effettua una verifica finale e decide se accettare o
meno la richiesta di prestito. Infine l’utente decide se accettare o rifiutare il prestito, terminando
così l’intero processo.
13

Workflow Capitolo 2
Figura 2 - Workflow di Click4aLoan
14

Workflow Capitolo 2
Lo scopo di questo caso di studio è quello di offrire un processo base da poter scomporre in
differenti sottoprocessi da eseguire su diversi server, anche detti “peer”, per coprire i diversi
scenari individuabili nel contesto dei workflow distribuiti. Questi scenari verranno presentati e
illustrati dettagliatamente nel capitolo 5.
2.3.2. Click4aCar
Questo secondo caso di studio è stato introdotto in quanto si adatta in modo più adeguato ad un
particolare scenario di distribuzione di workflow che tratteremo rispetto al caso di studio
precedente, in quanto è necessario avere due flussi di processo separati; per questo motivo
abbiamo scelto lo scenario della compravendita di macchine usate.
In questo caso abbiamo due workflow indipendenti, uno riguardante le auto, che viene gestito da
un’applicazione che rappresenta un concessionario, e uno riguardante l’utente, proprio di
un’applicazione che gestisce i clienti del concessionario.
Il workflow delle auto è quello riportato in figura 3:
Car
Manufacture Matriculation For Sale Purchase / Sale x
Demolition
Figura 3 - Workflow delle auto
Il flusso di processo relativo ad un auto inizia con la sua fabbricazione, continua con la sua
immatricolazione e prosegue con delle attività che rappresentano la compravendita dell’auto.
Queste attività comprendono “For Sale”, in cui l’auto viene messa in vendita per consentirle la
ricerca da parte dell’acquirente, e “Purchase / Sale” che conclude le operazioni di compravendita;
esse possono essere eseguite più volte, a seconda del numero di transazioni che avvengono nel
sistema. L’ultima fase, che porta al completamento del flusso di processo relativo ad un’auto, è la
demolizione.
User
Figura 4 - Workflow degli utenti
15

Workflow Capitolo 2
Il workflow degli utenti inizia con la ricerca di un’auto e prosegue, dopo l’acquisto, con il suo
utilizzo, per continuare poi con una attività di messa in vendita dell’auto. A questo punto il flusso di
lavoro ritorna alla fase iniziale di ricerca delle auto.
I due workflow interagiscono fra loro solamente a fronte di una richiesta di acquisto o vendita di
un’auto.
Questo caso di studio ci offre la possibilità di ricavare svariate combinazioni di interazione fra le
due tipologie di workflow. Quella più semplice riguarda il solo workflow relativo alle auto, utilizzato
dalla concessionaria, che immatricola le auto, le acquista per se, e in seguito le demolisce. A
questo è possibile aggiungere un’istanza del workflow degli utenti, rappresentando un cliente che
desideri acquistare o vendere la propria auto esclusivamente al concessionario. A questo scenario è
possibile inserire altre istanze del workflow degli utenti, senza un limite massimo, per
rappresentare un sistema di compravendita che coinvolga svariati utenti.
16

Web Service Capitolo 3
3. Web Service
17

Web Service Capitolo 3
Le varietà di sistemi informativi riscontrabili, al giorno d’oggi, presso le aziende che compongono
una qualsiasi filiera, comportano una molteplicità di modalità di scambio delle informazioni e di
interazioni con le applicazioni, necessitando di adottare soluzioni che favoriscano l’integrazione
attraverso l’utilizzo di standard di interazione che riducano la varietà di formati e quindi
diminuiscano i costi di transizione.
Per consentire l’interazione a livello applicativo tra componenti e sistemi informatici realizzati su
piattaforme tecnologiche diverse (es. Java/J2EE, .NET, COM+, Unix/Linux, ecc.) connessi tra loro
tramite Internet, vengono oggi utilizzati i Web Service.
Un Web Service è un sistema software creato per supportare interazioni macchina-macchina su una
rete. Presenta un’interfaccia descritta in un formato di specifica standard (WSDL). Gli altri sistemi
interagiscono con i Web Service nelle modalità descritte nella sua specifica, utilizzando messaggi
SOAP (Simple Object Access Protocol), in formato XML tipicamente trasmessi utilizzando HTTP. Le
applicazioni software scritte in vari linguaggi di programmazione ed eseguiti su varie piattaforme
possono utilizzare i Web Service per scambiarsi dati o informazioni su reti come Internet in maniera
molto simile a quanto avviene nella comunicazione tra processi su un unico computer.
I vantaggi che comporta l’integrazione a livello applicativo fornita dai Web Service sono molteplici:
in primo luogo si può operare sia in real-time sia in modalità differita; inoltre sfruttando le
funzionalità dell’applicazione che espone i Web Services si riduce il rischio di inconsistenze nei dati
gestiti.
A complemento dello standard XML/SOAP, i Web Services prevedono la possibilità di utilizzare due
standard complementari, sempre basati su XML:
WSDL (Web Services Description Language): è un formato basato su XML per la descrizione
di servizi remoti, con il quale è possibile descrivere l’interfaccia pubblica dei Web Services,
in modo da fornire una modalità attraverso la quale altri soggetti possono sapere come
accedervi.
WSDL è spesso usato in combinazione con SOAP e XML Schema per fornire Web Services
attraverso Internet. Un client che si connette ad un Web Service può leggere il WDSL per
determinare quali funzioni fornisce il server. Ogni tipo speciale di dato usato, è incluso nel
file WSDL in formato XML Schema. Il client può quindi usare SOAP per chiamare una delle
funzioni elencate nel WSDL.
18

Web Service Capitolo 3
UDDI (Universal Description, Discovery, and Integration): è un registro basato su XML che
affronta le problematiche di pubblicazione e reperimento dei servizi consentendo sia
l’accesso alla descrizione e alle tipologie dei servizi e dei fornitori secondo una struttura ben
definita, sia l’estrazione della tecnologia utilizzata nella realizzazione del servizio. Questo
permette l’integrazione tra servizi realizzati con tecnologie differenti e la ricerca utilizzando
chiavi diverse. Esso quindi non è un contenitore di servizi, ma uno strumento che tiene
traccia della loro dislocazione e delle loro descrizioni.
Naturalmente, quando si crea un Web Service, non è strettamente necessario crearne anche la
descrizione WSDL e tantomeno pubblicarla in un registro UDDI. Questo soprattutto se l’utilizzo del
Web Service viene riservato ad un numero ristretto di soggetti, nel qual caso le stesse informazioni
possono essere fornite direttamente.
Il loro utilizzo può essere sincrono o asincrono, delineando quindi due modelli di funzionamento: il
primo (sincrono) si basa sul paradigma client/server su Internet: il client richiede al server
l’informazione di cui necessita e attende che il server risponda con il dato richiesto prima di
continuare l’elaborazione; il secondo (asincrono) consiste in uno scambio di messaggi XML
attraverso Internet in maniera differita e programmata, senza una interazione real-time.
Figura 5 - Ricerca tramite UDDI ed invocazione di un Web Service
In figura 5 è riportato lo schema di funzionamento di una generica interazione tra Client, Registry e
Web Service:
19

Web Service Capitolo 3
• Il Service Provider, innanzitutto, pubblica la descrizione WSDL del servizio che vuole
rendere pubblico su un registry UDDI.
• Il Service Requester, interessato ad utilizzare un determinato servizio, si connette ad un
Service Broker ed effettua una ricerca del servizio desiderato nel registry UDDI.
• Una volta trovato il servizio che soddisfa le richieste del Client, viene ritornata a
quest’ultimo la descrizione dell’interfaccia pubblica del Web Services e la metodologia con
la quale comunicare con lo stesso.
• A questo punto il Service Requester può invocare direttamente il servizio web fornito dal
Service Provider e comunicare con esso attraverso messaggi SOAP.
3.1. Coreografia e orchestrazione
I processi tuttora implementati, necessitano di adattarsi velocemente alle necessità del cliente e
alle continue evoluzioni del mercato. Per garantire che la progettazione dei processi di business sia
flessibile e relativamente semplice si sente la necessità di uno standard che descriva
dettagliatamente i vari passi della progettazione.
Tale standard dovrebbe regolamentare la gestione delle interazioni sia di EAI (Enterprise
Application Integragration) che B2B attraverso i Web Services [9].
L’interazione fra Web Service può essere affrontata a due livelli di astrazione: il livello di
orchestrazione e il livello di coreografia.
L’orchestrazione di Web Services fornisce un approccio standard e aperto per l’interazione fra
questi servizi permettendo la creazione di processi di business ad un livello più alto, descrivendo
inoltre come i Web Services possono interagire tra loro a livello di messaggi scambiati, includendo
la logica di business e l’ordine di esecuzione delle interazioni, le quali possono coinvolgere più
applicazioni, server e/o organizzazioni. Il risultato consiste nella specifica di un processo di
business “long-running” di alto livello che descrive un’applicazione eseguibile da un proprietario, il
quale può esporre come nuovo servizio il processo risultante.
La coreografia tiene traccia delle sequenze di messaggi che possono coinvolgere più applicazioni
od organizzazioni attraverso una visione globale del processo, e punta a fornire una
rappresentazione più collaborativa delle interazioni, descrivendo i processi ad un livello più alto
20

Web Service Capitolo 3
rispetto all’orchestrazione. Gli attori coinvolti si trovano tutti allo stesso livello e non è presente un
proprietario del processo come avviene per l’orchestrazione.
Nella recente storia dell'informatica sono state ideate diverse proposte di standard basate su XML
che permettono di coprire sia l’orchestrazione che la coreografia di Web Services:
XLang (Microsoft BizTalk language), nato per descrivere interazioni tra Web Services in
Microsoft BizTalk Server e pesantemente basato su WSDL, estendendolo con alcune primitive
per descrivere il comportamento reciproco dei Web Services. Permette inoltre di specificare
sequenze, condizioni ed esecuzioni parallele di Web Services e può gestire eventuali eccezioni
durante l’esecuzione.
WSFL (Web Services Flow Language), che fornisce due livelli di specifica (assimilabili a
orchestrazione e coreografia):
- Flow Model (orchestrazione) che descrive un business process in termini di interazioni
tra Web Services, specificando i possibili usage patterns riguardanti le possibili
combinazioni corrette di Web Services e gli obiettivi che queste consentono di ottenere.
- Global Model (coreografia) che descrive gli interaction pattern di un insieme di Web
Services, ovvero una visione globale delle possibili interazioni tra molti partner.
WSCL (Web Services Conversation Language), che fornisce semplici concetti per descrivere
conversazioni tra servizi, attraverso: cinque tipi di interazioni (Send, Receive, SendReceive,
ReceiveSend, Empty), e transizioni: per descrivere l’ordine delle interazioni, le quali a loro
volta sono associate ai document types che vengono scambiati.
BTP (Business Transaction Protocol), che copre transazioni “long-running” basate su Web
services. È più orientato alla transazionalità ed estende il noto protocollo di commit a 2 fasi al
mondo dei Web Services, introducendo appositi messaggi (prepare(d), commit(ted),
cancel(led)) e i concetti Atom, assimilabili alle “vecchie” transazioni, e Cohesion, che possono
comporre atoms, ma sono più flessibili, consentono, ad esempio, parziali fallimenti di alcuni
partecipanti.
ebXML (Electronic Business using XML), che descrive un’infrastruttura complessa per la
comunicazione tra applicazioni di e-commerce, comprendendo aspetti architetturali,
implementativi e di specifica (BPSS - Business Process Specification Schema), tra cui concetti
legati alle conversazioni tra Web Services.
21

Web Service Capitolo 3
WSCI (Web Services Choreography Interface), che descrive il comportamento interattivo tra
Web Services osservabile dall’esterno, supportando correlazione di messaggi, regole di
sequenza, gestione delle eccezioni, transazioni e collaborazione dinamica.
BPEL4WS (Business Process Exec. Lang. for WS), è il risultato della fusione tra XLang e
WSFL, e rappresenta uno strato al di sopra di WSDL, in 3 sensi:
- Ogni processo BPEL può essere esposto come servizio in WSDL (che descrive entry ed
exit point del processo stesso).
- Sfrutta data types definiti in WSDL per descrivere il passaggio di informazioni.
- Può referenziare servizi esterni specificati in WSDL.
Consente di specificare l’orchestrazione di Web Services attraverso il concetto di “Executable
Process” e i partecipanti in una business interaction; ed inoltre di specificare coreografie per
mezzo del concetto di “Business Protocol”, descrivendo un abstract process, cioè la parte
visibile dall’esterno (messaggi scambiati tra i partner), e trascurando i dettagli del flusso di
processo.
22

WebML Capitolo 4
4. WebML
23

WebML Capitolo 4
Oggi le applicazioni Web basate sui dati sono il tipo di applicazioni più diffuse sul Web e hanno la
necessità di gestire e pubblicare una grande mole di dati. Lo sviluppo e la manutenzione di tali
applicazioni necessita degli strumenti e delle tecniche trattati dall’ingegneria del software, che
comprendono le seguenti caratteristiche: definizione di un processo di sviluppo del software ben
organizzato, concetti di progettazione e notazioni appropriati e linee guida per la conduzione delle
varie attività.
Web Modeling Language (WebML) [5], un linguaggio di modellazione di alto livello per la specifica
di applicazioni Web, segue lo stile di linguaggi di modellazione noti, come il modello Entità-
Relazione e UML, permettendo così di rappresentare graficamente ogni concetto e di offrirne una
specifica attraverso diagrammi visuali. Questi diagrammi visuali permettono di descrivere un
ipertesto, definito come un insieme di pagine costituite da unit di contenuto e operazioni collegate
tra loro, permettono la progettazione della struttura dati per poter memorizzare i contenuti e la
creazione di stili grafici per le applicazioni trattate.
I principali obiettivi del processo di modellazione WebML sono:
Esprimere la struttura di un applicazione Web mediante una descrizione ad alto livello,
utilizzata per progettare e sviluppare l’applicazione stessa.
Permettere di avere a disposizione diversi punti di vista per lo stesso contenuto.
Definire e sviluppare separatamente gli elementi della logica a tre livelli: dati, navigazione
e presentazione.
Permettere di raccogliere informazioni in un repository, che può consentirne un utilizzo
differito per la generazione dinamica delle pagine web.
Realizzare politiche di personalizzazione di accesso e contenuti mediante la modellazione
esplicita di utenti e gruppi.
Permettere modifiche all’applicazione o l’interazione con applicazioni esterne mediante
operazioni di manipolazione dei dati.
WebML, nella specifica delle applicazioni Web Data-Intensive, segue tre prospettive distinte e
ortogonali per la modellazione:
modello dei dati
modello di ipertesto
modello di presentazione
24

WebML Capitolo 4
Figura 6 - Struttura a tre livelli di WebML
4.1. Modello dei dati
Lo scopo della modellazione dei dati è quello di specificare in modo formale e intuitivo i dati che
verranno utilizzati nell’applicazione. Tale modellazione è un’operazione preliminare, e permette,
tramite uno schema concettuale, di riassumere in modo semplice e comprensibile i dati applicativi.
Questo schema concettuale viene realizzato mediante la notazione più diffusa per la modellazione
di database: il modello Entità-Relazione. Gli ingredienti essenziali di questo modello sono le Entità,
che rappresenta una descrizione delle caratteristiche comuni di un insieme di oggetti del modo
reale, e le Relazioni, che rappresentano connessioni semantiche tra le entità.
Le entità sono descritte tramite attributi, che rappresentano le proprietà degli oggetti del mondo
reale, rilevanti per l’applicazione. Essi sono associati alle entità ed indicano che tutte le istanze
dell’entità sono caratterizzate dallo stesso insieme di attributi.
Le relazioni permettono di realizzare connessioni semantiche tra le entità. La forma più semplice di
relazione è la relazione binaria, che connette due entità. Questo tipo di relazione è caratterizzata
da due ruoli di relazione, ognuno dei quali esprime la funzione che una delle entità gioca nella
partecipazione alla realizzazione. I ruoli delle relazioni possono essere annotati con dei vincoli di
cardinalità minimo e massimo, che indicano il numero minimo e massimo di oggetti dell’entità di
destinazione a cui un oggetto dell’entità sorgente può essere collegato. Valori rilevanti per la
cardinalità minima sono zero e uno, mentre per quelle massime sono uno o molti, quest’ultimo
rappresentato dal simbolo N.
25

WebML Capitolo 4
Figura 7 - Modello dei dati
La figura mostra uno schema di dati che permette la gestione degli utenti, dei loro gruppi di
appartenenza e delle site-view, cioè le aree dell’applicazione web associate ai vari gruppi di utenti.
Un utente è caratterizzato da un ID univoco, da un nome utente, da una password e da una e-mail;
un gruppo da un ID e da un nome; una site-view da un ID numerico e da un ID nominale. Un
utente può appartenere da uno a N gruppi, mentre ha un solo gruppo di default; a sua volta un
gruppo può avere e può essere gruppo di default di uno o N utenti; inoltre un gruppo è associato
ad una sola site-view, mentre una site-view può essere associata a più gruppi.
4.2. Modello di ipertesto
Lo scopo della modellazione ipertestuale è quello di specificare l’organizzazione dell’interfaccia di
un’applicazione Web e di esprimere in modo semplice ed intuitivo aspetti quali la suddivisione
logica dell’applicazione in moduli di alto livello, la loro partizione in sotto-moduli e la topologia
dell’ipertesto di ogni modulo in termini di pagine, costituite da elementi di contenuto e link che
supportano la navigazione e l’interazione dell’utente. WebML fornisce le primitive per la
modellazione ipertestuale utilizzando concetti semplici ed espressivi propri del modello Entità-
Relazione.
Gli ingredienti chiave sono le pagine, le unit e i link, organizzati in costrutti modulari detti aree e
site-view. Le unit rappresentano le parti atomiche di contenuto da pubblicare e costituiscono gli
elementi base delle pagine. Questi due elementi sono collegati tramite link per formare una
struttura ipertestuale, i quali permettono la navigazione nell’ipertesto e il passaggio di parametri da
una unit all’altra, requisito necessario per il corretto calcolo del contenuto di una pagina. Un
insieme di pagine può essere raggruppato in una site-view, che sono un costrutto modulare per
raccogliere le aree, le pagine, le unit e i relativi link. Infine, a livello di site-view è possibile
26

WebML Capitolo 4
specificare dei parametri globali per denotare delle informazioni che devono essere memorizzate e
riutilizzate durante la navigazione dell’utente.
4.2.1 Site-view
Una site-view rappresenta un ipertesto coerente per soddisfare un insieme ben definito di requisiti,
per esempio relativi ad uno specifico gruppo di utenti. Le site-view più complesse possono essere
decomposte gerarchicamente in aree, ovvero gruppi di pagine con uno scopo omogeneo, le quali
sono contenitori di pagine, o in modo ricorsivo, di altre sottoaree.
4.2.2 Pagine
Le pagine costituiscono gli elementi di interfaccia forniti all’utente, il quale naviga l’ipertesto
accedendo alle sua pagine secondo la sequenza desiderata. Tipicamente una pagina contiene
diverse unit, raggruppate per specificare concetti ben definiti.
Le pagine e le aree sono caratterizzate da alcune proprietà che evidenziano la loro importanza nel
sito Web; in particolare, le pagine possono avere le seguenti tre proprietà:
- Home, è la pagina all’indirizzo di default del sito, o che viene presentata dopo che l’utente
effettua la login. Deve essere unica all’interno della site-view e viene denotata col simbolo
“H” all’interno dell’icona della pagina.
- Default, è la pagina presentata di default quando si accede all’area che la racchiude. Deve
essere unica all’interno di un’area e viene denotata da una “D” all’interno dell’icona della
pagina.
- Landmark, è una pagina raggiungibile da tutte le altre pagine o aree all’interno del modulo
che la racchiude. Viene denotata da una “L” all’interno dell’icona della pagina.
4.2.3 Unit
Le unit (o unità di contenuto) sono gli elementi atomici per specificare il contenuto di una pagina
web, e corrispondono ad una “vista” definita su di un contenitore di oggetti, che permette di
specificare tutte le istanze di un’entità sorgente o solo quelle che soddisfano una condizione di
selezione chiamata selettore.
Ogni unit può avere parametri di input e output. I parametri di input sono i parametri richiesti dal
selettore della unit, mentre quelli di output possono essere utilizzati per la computazione di una o
più unit che dipendono dalla unit corrente.
27

WebML Capitolo 4
WebML supporta cinque tipi di unit:
Data Unit
Multidata
Unit
Index Unit
Utilizzata per pubblicare dati di un singolo oggetto di una
determinata entità; ed è caratterizzata dalle seguenti proprietà:
Nome, Sorgente (Entità che fornisce il contenuto alla unit),
Selettore (per identificare un unico oggetto) e attributi da
visualizzare.
Permette di presentare un insieme di oggetti di un’entità, ripetendo
la presentazione di molte unit Data, ed è caratterizzata dalle
seguenti proprietà: Nome, Sorgente (Entità che fornisce il
contenuto alla unit), Selettore (per identificare un unico oggetto),
attributi da visualizzare e clausola di ordinamento.
Permette di presentare un insieme di oggetti di un’entità come una
lista, ed è caratterizzata dalle seguenti proprietà: Nome, Sorgente
(Entità che fornisce il contenuto alla unit), Selettore (per
identificare un unico oggetto), attributi da visualizzare e clausola di
ordinamento. Una unit Index viene tipicamente utilizzata per
selezionare un particolare oggetto, a differenza della unit Multidata,
che viene invece utilizzata per elaborare tutti gli oggetti mostrati.
La unit Index ammette due varianti:
- Multi-choice Index Unit: ogni elemento della lista è
associato ad una casella di scelta che permette all’utente di
selezionare un insieme di oggetti anziché un singolo
oggetto.
- Hierarchical Index Unit: le voci dell’indice sono
organizzate secondo un albero a più livelli.
Scroller
Unit
Entry Unit
Fornisce i comandi per navigare una sequenza di oggetti, per
esempio tutte le istanze di un’entità, ed è caratterizzata dalle
seguenti proprietà: Nome, Sorgente (Entità che fornisce il
contenuto alla unit), Selettore (per identificare un unico oggetto),
Block Factor (numero di elementi di un blocco) e clausola di
ordinamento.
Supporta l’inserimento dei dati tramite form, viene utilizzata per
ricevere gli input dall’utente, che viene tipicamente impiegato per
effettuare ricerche all’interno di un insieme di oggetti di un entità o
fornire i parametri a operazioni che aggiornano il contenuto della
base di dati. È caratterizzata dalle seguenti proprietà: Nome,
Campi (per l’inserimento dei valori).
28

WebML Capitolo 4
4.2.4 Operation
WebML include inoltre diverse operazioni, che rappresentano le primitive più comunemente usate
per aggiornare le istanze delle entità e delle relazioni dell’applicazione. Le operation unit di WebML
sono delle unit che possono essere posizionate all’esterno delle pagine, che a differenza delle unit
di contenuto non hanno lo scopo di pubblicare informazioni, ma eseguono semplicemente
un’azione. Esse sono collegate ad altre operazioni o unit tramite link, possono avere un oggetto
sorgente e dei selettori.
WebML fornisce delle operazioni predefinite, per il controllo degli accessi e per l’invio di e-mail, e
generiche:
Operazioni predefinite:
Create Unit
Delete Unit
Modify Unit
Connect Unit
Disconnect
Unit
Permette di creare una nuova istanza di attività, ed è caratterizzata
da un nome, dall’entità sorgente su cui si applica l’operazione e un
insieme di assegnamenti che legano gli attributi dell’oggetto da
creare con i valori dei parametri passati.
Permette di eliminare uno o più oggetti di una determinata entità,
ed è caratterizzata da un nome, dall’entità sorgente e dal selettore
che determina gli oggetti su cui si applica l’operazione.
Permette di aggiornare uno o più oggetti di una determinata entità,
ed è caratterizzata da un nome, dall’entità sorgente, dal selettore
che determina gli oggetti su cui si applica l’operazione e un insieme
di assegnamenti che associano i nuovi valori agli attributi degli
oggetti da modificare.
Permette di creare nuove istanze di una relazione e si applica a uno
dei due possibili ruoli di una relazione e crea una o più istanze del
ruolo della relazione che connette alcuni oggetti all’entità sorgente
con alcuni oggetti dell’entità destinazione. È caratterizzata da un
nome, dal ruolo della relazione al quale si applica l’operazione e da
due selettori, uno per individuare gli oggetti dell’entità sorgente, e
uno per gli oggetti dell’entità destinazione.
Permette di cancellare le istanze di una relazione e si applica a uno
dei due possibili ruoli di una relazione e cancella le connessioni tra
alcuni oggetti dell’entità sorgente e alcuni oggetti dell’entità
destinazione. È caratterizzata da un nome, dal ruolo della relazione
al quale si applica l’operazione e da due selettori, uno per
individuare gli oggetti dell’entità sorgente, e uno per gli oggetti
dell’entità destinazione.
29

WebML Capitolo 4
Operazioni per il controllo degli accessi e per l’invio di e-mail:
Login Unit
Logout Unit
SendMail Unit
Permette il controllo degli accessi e la verifica dell’identità di un
utente che accede al sito. Controlla la validità dei parametri inseriti
(nome utente e password) e porta l’utente alla home-page della
sua site-view di default.
Viene utilizzata per far terminare la sessione di un utente e
portarlo ad una pagina di default in cui non vi è il controllo
dell’accesso. Essa non ha parametri di input e di output.
Permette di inviare un messaggio di posta elettronica, ed è
caratterizzata da cinque parametri: il testo del messaggio,
l’insieme degli indirizzi dei destinatari, l’indirizzo del mittente,
l’oggetto del messaggio ed un insieme di allegati.
Operazioni generiche:
Operation
Unit
Permette di definire operazioni generiche la cui specifica è data
semplicemente dal nome dell’operazione. Viene eseguita al di fuori
del contesto WebML.
4.2.5 Link
Le pagine e le unit possono essere collegate tramite link, che permettono di specificare i possibili
percorsi navigazionali tra le pagine, le possibili selezioni offerte all’utente e l’effetto dell’interazione
dell’utente sul contenuto delle unit visualizzate nella pagina. Le nozioni principali del modello
navigazionale, sono i concetti di:
- Link: collegamento orientato tra due unit o pagine.
- Parametro del link: specifica di un’informazione che viene trasportata dalla sorgente alla
destinazione di un link.
- Selettore parametrico: selettore di una unit i cui predicati contengono riferimenti a dei
parametri di link.
I link possono essere utilizzati anche per specificare particolari tipi di flussi di informazione tra unit,
che avvengono senza l’intervento dell’utente. Ne esistono due tipologie:
- Automatici: vengono navigati senza l’intervento dell’utente e propagano l’informazione
contestuale scelta in modo automatico dalla unit sorgente a quella di destinazione.
30

WebML Capitolo 4
- Di trasporto: vengono utilizzati solamente per passare informazione contestuale da una
unit ad un’altra. Abilita solamente il passaggio di parametri e non la navigazione
dell’utente.
Una particolare tipologia di link è rappresentata dai link uscenti dalle unit che rappresentano
operazioni, che si distinguono in OK-Link e KO-Link, che catturano rispettivamente gli eventi di
successo e di fallimento dell’operazione, permettendo al progettista di scegliere azioni alternative
dopo l’esecuzione di un’operazione a seconda del risultato della sua esecuzione.
4.2.6 Parametri globali
Esistono delle situazioni in cui le informazioni contestuali non vengono trasferite punto a punto
durante la navigazione, ma devono essere disponibili “globalmente” a tutte le pagine del sito. Per
questo motivo WebML offre la nozione di parametro globale, che consiste in un’informazione
associata alla sessione dell’utente, che può essere impostata esplicitamente durante la navigazione
dell’ipertesto ed estratta successivamente per calcolare il contenuto di alcune unit, attraverso due
unit apposite chiamate “Set Unit” e “Get Unit”.
4.3. Modello di presentazione
Il modello di presentazione descrive come appaiono graficamente le pagine web indipendentemente
dal linguaggio usato per la loro pubblicazione.
La progettazione della presentazione consiste nella definizione dei fogli di stile XSL contenenti le
regole di presentazione necessarie a produrre i template di pagina. Un foglio di stile XSL consiste in
un insieme di regole che governano il modo in cui l’intera pagina e i vari tipi di unit vengono
generati.
Partendo dal modello WebML generato è poi possibile ottenere automaticamente il codice di
navigazione dei dati in un linguaggio di scripting come ASP o JSP.
31

WebML Capitolo 4
4.4. Estensione di WebML per i Workflow
Scopo di questa sezione è quello di mostrare come è stato arricchito il linguaggio WebML per poter
integrare gli ipertesti con le funzionalità offerte dai workflow [10, 19], il che significa sviluppare
interfacce web che permettano l’esecuzione di attività e che esprimano dei vincoli che permettano
di guidare l’utente nella navigazione. Il processo di sviluppo di ipertesti guidati da workflow è
centrato su una modellazione concettuale che integra tre prospettive ortogonali: modello di
processo, modello dei dati e modello di ipertesto.
4.4.1. Modello di processo
Il modello di processo rappresenta il processo che deve essere eseguito, nei termini delle attività
che lo compongono, i suoi vincoli di precedenza e gli attori incaricati di eseguire ogni attività.
I concetti e le notazioni alla base del modello di processo sono stati affrontati in modo dettagliato
nel capitolo 2.
4.4.2. Modello dei dati
Per poter gestire i dati relativi ad un workflow in WebML, è stata introdotto un meta-modello dei
dati apposito, integrato con i dati propri dell’applicazione. Esso include le entità e le relazioni
richieste per gestire uno o più workflow.
Figura 8 - Meta-modello dei dati per i workflow
32

WebML Capitolo 4
La figura mostra lo schema base del meta-modello dei dati per i workflow ed include:
- I processi, cioè le descrizioni dei workflow processati e supportati.
- I cases, le istanze di processo sono create, gestite ed eventualmente terminate dal
workflow management system, e caratterizzate da uno stato di esecuzione.
- Le attività che compongono il processo.
- Le activity instance, cioè le istanze individuali di un’attività all’interno di un case. Possono
essere assegnate ad utenti specifici o ad un gruppo di utente e sono eseguite da un unico
utente. Anch’esse sono caratterizzate da uno stato.
- I partecipanti del workflow, come gli utenti che svolgono il lavoro correlato alle activity
instances. I partecipanti al workflow sono organizzati in utenti e gruppi, i quali possono
essere usati per controllare l’accesso all’applicazione web.
Più precisamente, le entità componenti il meta-modello dei dati per i workflow sono le seguenti:
- PROCESS: Contiene la descrizione del processo utilizzato dall’applicazione, ed è
caratterizzato da: Nome, Descrizione, ID.
- CASE: Memorizza le istanze dei 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 è uno tra
[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 è uno tra [Active, Inactive,
Complete, Suspended, Terminated, Archived]
33

WebML Capitolo 4
Come possiamo notare i dati relativi alla nostra applicazione (Work Item) 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à, così come le istanze di attività sono relazionate
con zero o N applicazioni.
4.4.3. Modello di ipertesto
La modellazione di un ipertesto guidato da workflow potrebbe essere vista come una naturale
estensione della modellazione di pagine e aree classiche. In particolare, pagine e aree possono
essere utilizzate per rappresentare attività e unità di operazione per gestire il workflow.
Il contenuto delle pagine che costituiscono le attività sono rappresentate da contenuti WebML e
operation units. Per poter definire un’attività, sono state aggiunte al modello di ipertesto standard
le seguenti operazioni:
Start / End
Start / end activities: le pagine costituenti un’attività devono
essere racchiuse tra questi due simboli. Perché un’attività possa
iniziare bisogna che siano verificate due precondizioni:
la presenza delle informazioni:
- Activity type: un’attività deve essere associata ad un
singolo Activity type.
- User: chi deve eseguire l’attività.
- Case: il case nel quale l’attività deve essere svolta.
i parametri globali:
- Current user: chi svolgerà l’azione.
- Current case: al quale l’attività sarà associata a runtime.
- Current activity istance.
Start / end cases: la prima attività del processo avvierà il
case, e l’ultima lo farà terminare. Se un’attività avvia un case,
saranno compiute le operazioni associate allo “starting case”. (es
crea un nuovo case, il cui stato è settato ad “attivo” e setta il
parametro globale “current case”). Le operazioni duali vengono
eseguite nel caso in cui l’attività faccia terminare il case.
Expression
Parsing Unit
Permette di valutare diverse espressioni (booleane,
matematiche), presentando in output un risultato in accordo con
i parametri in ingresso. Questa unit accetta l’espressione da
valutare come una proprietà. Le espressioni sono composte da
un numero variabile di predicati che devono essere forniti alla
unit come parametri di input.
34

WebML Capitolo 4
Switch Unit Utilizzata per selezionare diversi rami
decisionali, in base ad un singolo valore di
input. Ogni OK-link è associato ad un valore
costante che deve essere comparato con il
valore di input. Logicamente i vari rami
devono essere in disgiunzione tra di loro.
Test Unit E’ utilizzata per valutare espressioni booleane. Se
l’espressione in ingresso fosse vera si procederebbe verso
l’OK-link, in caso fosse falsa verso il KO-link. (trasportando in
uscita tale valore).
Workflow
Aware Index
Unit
Assign Unit
Questa unit viene utilizzata per estrarre dati relativi ad
un’istanza di una attività. Essa estrae solo le istanze relative
ad una data attività se questa appartiene ad un tipo
prefissato (Activity ID), ha un particolare stato, appartiene ad
un case che abbia un determinato stato, o che sia assegnata
ed eseguita dall’utente corrente.
Questa unit viene utilizzata per assegnare degli oggetti
dell’applicazione (dati) ad una particolare istanza di attività.
Scopo di questa unit è quello di definire “link di dati” tra le
attività, e di assegnare dati ad uno specifico utente.
Quando un’attività produce un dato da usare in un’altra
attività, esso può essere passato all’altra attività
assegnandolo come un’attività. Questi oggetti da passare
devono appartenere ad un’entità connessa all’ entità “Activity
Istance”.
Get Activity
Status Unit
Viene utilizzata per ottenere lo stato di una attività.
35

WebML Capitolo 4
4.5. Estensione di WebML per i Web Service
Scopo di questa sezione è quello di mostrare come è stato integrato il linguaggio WebML [11, 19,
20] per poter dare la possibilità al progettista di utilizzare la tecnologia dei Web Service nelle
applicazioni web.
4.5.1. Primitive per la descrizione e la pubblicazione di servizi
L’estensione di WebML per i Web Service permette di pubblicare schemi di ipertesto come dei Web
Service, tramite le primitive standard di ipertesto e la unit Synchronous Solicit-Response Service
Operation, utilizzata per processare un messaggio da un client e per comporre l’appropriata
risposta.
La unit Solicit-Response si presenta col seguente simbolo:
Solicit Response
Figura 9 - Simbolo della unit Solicit-Response
L’unica proprietà di questa unit è il suo Nome, è possibile creare parametri di input attraverso il
menu contestuale (“Add Parameter”).
Le site-view che contengono i servizi pubblicati devono avere particolari caratteristiche:
- Deve essere aggiunta la proprietà personalizzata “ApplicationBaseAddress” col valore
“http://localhost:{http-port}/{application-name}” per poter impostare l’indirizzo
base dell’applicazione.
- Deve essere aggiunta la proprietà personalizzata “ServiceGroup” col valore “Yes” per poter
definire una site-view che permetta di pubblicare un web service.
- Il layout di pagina deve essere impostato sul valore “SOAP Envelope” per permettere
all’applicazione di generare file di configurazione SOAP al posto di pagine JSP. Inoltre deve
essere selezionato lo stylesheet “Web services” per poter generare documenti XML al posto
di pagine HTML.
36

WebML Capitolo 4
Per ogni site-view di questo tipo viene creato un file di configurazione SOAP, che contiene le
informazioni necessarie riguardanti sia il progetto sia ogni Web Service che viene pubblicato. In
questo file sono contenute le seguenti informazioni:
- L’application base address che definisce l’indirizzo dell’applicazione.
- Per ogni unit Solicit-Response sono registrati i dati:
o
o
o
o
o
Soap-path: che definisce l’end-point-url del Web Service.
Tag-name: che definisce il nome del Web Service.
Id: l’id della unit Solicit-Response.
Operation-type: che definisce il tipo di Web Service, Solicit-Response o Notification.
Url-path: l’id della unit o della pagina che seguono direttamente la unit Solicit-
Response.
- Per ogni parametro definito per la unit Solicit-Response sono registrate le seguenti
informazioni:
o
o
Url-name: la destinazione del parametro.
Tag-name: il nome del parametro.
Un esempio di pubblicazione di Web Service è mostrato in figura, dove sono riportate una unit
Solicit-Response e una pagina contenente una lista dei prestiti da restituire.
Loan Types
getLoanTypes
Loan Types
Index
Loan Proposal
Ed il relativo file di configurazione SOAP:
Figura 10 - Esempio di pubblicazione di Web Service
37

WebML Capitolo 4
Per ogni unit Solicit-Response viene generato un file WSDL a livello di presentazione, e contiene le
seguenti informazioni:
- Types: L’elemento wsdl:types racchiude le definizioni dei tipi di dati rilevanti per i messaggi
scambiati dal Web Service, specificati per mezzo del linguaggio XML Schema.
Per poter generare il file WSDL automaticamente sono assunte le convenzioni:
o
Il nome dei tipi di output ritornati dal Web Service è il nome dei messaggi di
risposta.
o
Il contenuto dei tipi di output racchiude il nome dell’entità sulla quale la content
unit è definita (Loan Proposal), ed è composto dagli attributi mostrati dalla content
unit ed i rispettivi tipi. Ogni tipo di dato WebML viene mappato in un tipo di dato
XML Schema, come mostrato nella tabella:
Tipo WebML
String
Text
Integer
Number
Float
Date
Boolean
URL
BLOB
Tipo XML Schema
s:string
s:string
s:int
s:double
s:float
s:date
s:Boolean
s:string
s:string
- Messages: nel caso di un’operazione di Solicit-Response contiene due messaggi, uno per la
richiesta e uno per la risposta; mentre nel caso di un’operazione di Notification contiene
solo un messaggio di input.
Per poter generare il file WSDL automaticamente sono assunte le convenzioni:
o
I nomi dei messaggi sono i nomi delle unit Solicit-Responce, che agiscono come end
point url del servizio col suffisso Request o Response.
o
Per ogni messaggio è definito un campo wsdl:part, dipendente dai parametri di
ingresso e di uscita del messaggio.
o
Per un messaggio di richiesta è definito un campo wsdl:part per ogni parametro di
ingresso della unit avente il nome del parametro e il tipo xsd:string.
o
Per un messaggio di risposta il wsdl:part è definito come specificato nell’elemento
wsdl:types.
38

WebML Capitolo 4
- PortType: la sezione wsdl:portType definisce il set di operazioni e di messaggi astratti del
servizio. Per poter generare il file WSDL automaticamente sono assunte le convenzioni:
o
o
Il nome dell’operazione è il nome della Solicit-Response unit.
I messaggi sono quelli definiti nella sezione definita precedentemente.
- Binding: il wsdl:binding definisce il formato dei messaggi e i dettagli del protocollo da
utilizzare per invocare l’operazione. Per poter generare il file WSDL automaticamente sono
assunte le convenzioni:
o
I messaggi sono definiti da un particolare wsdl:portType, che punta direttamente al
wsdl:portType definito nella sezione precedente.
o Viene utilizzato il protocollo SOAP 1.1.
- Service: il gruppo di elementi wsdl:service raggruppa un insieme di porte relazionate fra
loro. Attraverso l’elemento soap:address può essere definito l’end point url dove sarà
raggiungibile il Web Service. Per poter generare il file WSDL automaticamente sono assunte
le convenzioni:
o
L’indirizzo è la concatenazione dell Application Base Address e il soap-path della
unit Solicit-Response.
Riportiamo ora il file WSDL relativo all’esempio precedente:
targetNamespace="http://www.webratio.com"
xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="http://www.webratio.com"
xmlns:s0="http://www.webratio.com">
39

WebML Capitolo 4

WebML Capitolo 4
One-Way
Unit
La unit One Way è del tutto simile alla precedente, ad eccezione
del fatto che non prevede una risposta dal servizio Web
invocato.
Adapter
Unit
XML IN
Unit
XML OUT
Unit
Permette di applicare una trasformazione XSL [23] su un
documento XML in ingresso, fornendo il documento XML
trasformato come output. Può ricevere più di un documento in
ingresso, ma produce sempre un solo documento in uscita.
Permette di trasformare un documento XML in dati relazionali. I
documenti XML in ingresso solitamente vengono forniti da una
unit Request-Response o da una unit Adapter, e devono essere
in un formato canonico che permetta di costruire
automaticamente le entità e la relazioni nei database relazionali.
Questa unit non presenta output, il risultato della computazione
è salvato in un Database reale o in uno virtuale temporaneo.
Effettua l’azione duale rispetto alla unit precedente, in
particolare trasforma un frammento di schema E-R in un
documento XML canonico.
41

Workflow Distribuiti Capitolo 5
5. Workflow Distribuiti
42

Workflow Distribuiti Capitolo 5
La distribuzione dei processi è quella metodologia di design delle applicazioni mediante la quale
vengono assegnate le diverse attività, che compongono l’intero processo da modellizzare, ai vari
server che possono eseguirle e che non condividano necessariamente una stessa base di dati
contenente i meta-dati di processo [2, 21].
Le Attività sono unità atomiche di distribuzione, cioè dato un compito che può essere suddiviso in
varie sotto-attività, esso deve essere spezzato in attività più piccole da far eseguire ciascuna a
server differenti. La composizione di tutte queste sotto-attività (e del loro flusso di esecuzione),
rappresenta l’intero processo.
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 differenti.
Per questo motivo, ogni organizzazione fornisce dei Web Services mediante i quali l’utente remoto
può accedere ai dati locali di una organizzazione, e modificarli secondo una logica definita, per
evitare errori generici nel flusso delle operazioni da eseguire e per fornire una certa sicurezza
nell’accesso ai dati. Inoltre, essendo i nodi coinvolti nel processo interagenti tra 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, esprimeremo i
requisiti di distribuzione tramite la notazione BPMN, che ci permetterà di assegnare esplicitamente
varie attività ai diversi nodi, o peer, coinvolti nel processo, ed integreremo la distribuzione nel
modello ipertestuale, utilizzando le estensioni per i Workflow e i Web Service di WebML, che ci
consentiranno di pubblicare e invocare servizi remoti, nonché di gestire il relativo flusso di lavoro
tra i vari server.
Nell’ambito della distribuzione dei processi, possiamo individuare differenti scenari di distribuzione
delle attività, che verranno descritti con l’ausilio della notazione BPMN, la quale verrà estesa
tramite specifiche convenzioni, come il rappresentare ogni peer tramite un pool separato e lo
scambio di messaggi di richiesta e risposta delle comunicazioni tra i server tramite frecce di tipo
“Message Flow” che attraversano i pool. Inoltre adotteremo il tipo di evento “Message” per
rappresentare l’avvio dell’attività successiva a fronte della ricezione di un messaggio.
43

Workflow Distribuiti Capitolo 5
Per poter descrivere meglio le diverse varianti della distribuzione dei processi utilizzeremo i casi di
studio presentati nel capitolo 2, che permettono di comprendere con più chiarezza i vari approcci:
- Distribuzione di un singolo servizio, dove solo un servizio semplice viene delegato ad un
peer remoto.
- Distribuzione dei sotto-processi, dove vengono delegati ai peer remoti diverse attività del
processo, e in cui si possono identificare diverse metodologie di controllo del flusso di
processo:
o Controllo centralizzato
o Controllo distribuito
• Controllo distribuito annidato
• Controllo distribuito generalizzato
- Interazione fra processi indipendenti, dove vengono coinvolti due o più flussi di processo
che comunicano fra loro.
5.1. Distribuzione di un singolo servizio
Questo scenario rappresenta l’approccio più semplice alla distribuzione dei processi, in quanto non
vi è decentramento di attività o sotto-processi tra i vari server, ma riguarda solamente la
distribuzione di un servizio semplice.
Nella realtà questo scenario copre diversi contesti: il contesto in cui un’azienda intende pubblicare
un servizio per renderlo disponibile ad altre entità che sfruttano questo servizio per portare a
termine delle operazioni; il contesto in cui un’azienda desideri recuperare informazioni da basi di
dati remote e da applicativi già esistenti che le esportano per mezzo di Web Services.
In questo scenario, le operazioni svolte sul peer che esporta il servizio (remoto), non fanno parte
del flusso di processo, ma servono per portare a compimento una delle sue attività, che vengono
svolte tutte sullo stesso peer, detto principale, che mantiene in un unico database i dati necessari
all’applicazione e i meta-dati che permettono la gestione del workflow.
Il peer che fornisce il servizio semplice, non è coinvolto nel workflow e perciò non ne possiede i
meta-dati.
Questo scenario è stato applicato al caso di studio Click4aLoan per simulare il caso in cui le
proposte di prestito e le relative modalità di pagamento vengano rese disponibili da un servizio
remoto, e l’applicazione di gestione dei prestiti sfrutti l’invocazione di questo servizio per
44

Workflow Distribuiti Capitolo 5
presentare all’utente una lista delle proposte di prestito offerte dalle diverse banche, tra le quali
potrà scegliere quella desiderata.
In figura 11 è riportato il diagramma di processo del caso di studio Click4aLoan applicato a questo
scenario, descritto tramite la notazione BPMN:
Main Peer
Remote Peer
Applicant Manager Employee
Application
Request
Get Remote Data
Not Valid
Preliminary
Validation
x
Loan
x
Mortgage
+
Financial
Check
Financial
Check
Job
Check
Residence
Check
Residence
Check
+
Credit
Check
x
Final
Validation
x
Not Valid
Choice
Figura 11 - Distribuzione di un singolo servizio applicata al caso di studio Click4aLoan
45

Workflow Distribuiti Capitolo 5
Il diagramma si presenta come quello riportato nel capitolo 2, figura 2, dove l’intero workflow
risiede sul peer principale, fatta eccezione per la presenza di un peer remoto che rende disponibili i
dati relativi ai prestiti tramite la pubblicazione di un Web Service, invocato dal peer principale per
ottenere le informazioni da presentare all’utente.
5.2. Distribuzione dei sotto-processi
In questo scenario cominciamo ad affrontare la vera e propria distribuzione di attività e sottoprocessi
su diversi peer, la quale introduce una nuova dimensione all’attività di design, cioè la
scelta dell’ubicazione del controllo del processo distribuito.
Si possono infatti individuare diverse metodologie che il progettista può seguire per quanto
riguarda la scelta dei peer che dovranno occuparsi di gestire il flusso di processo.
Una prima metodologia può essere quella di delegare il controllo ad un unico peer centrale che
abbia costantemente una visione generale dello stato di avanzamento del processo e delle sue
attività, e in cui gli altri peer si limitino ad eseguire semplici attività atomiche. Una seconda è quella
in cui il controllo del processo viene distribuito tra i vari server, e in cui il peer centrale non ha
continuamente una visione completa dello stato di avanzamento delle attività, siccome la gestione
dei diversi sotto-processi è delegata ad altri peer. La coordinazione dei peer può seguire diversi
modelli di cui riconosciamo due varianti principali: coordinazione annidata e generalizzata.
5.2.1. Distribuzione con controllo centralizzato
Con il controllo centralizzato del processo, vi è un peer principale incaricato di mantenere lo stato
di avanzamento di tutte le attività di un determinato processo, anche quelle delegate ed eseguite
su altri server.
Questo scenario rappresenta il caso reale in cui un’azienda desideri delegare ad altre entità
l’esecuzione di operazioni atomiche che andranno a far parte del suo flusso di processo. Tali
operazioni, essendo atomiche, non richiedono a queste entità di dover essere a conoscenza del
flusso di operazioni del processo, e le sollevano dal mantenerne i meta-dati di workflow.
Per ogni attività delegata ad un peer remoto, verranno scambiati dei messaggi con il peer
principale unicamente all’attivazione o al completamente della stessa.
In figura 12 possiamo osservare un diagramma di sequenza che rappresenta l’interazione tra tre
peer differenti in un contesto di distribuzione con controllo centralizzato.
46

Workflow Distribuiti Capitolo 5
Le linee verticali denotano l’evoluzione temporale delle attività ed ogni numero corrisponde al loro
ordine di esecuzione. Nell’esempio possiamo vedere come il coordinatore (Main Peer) esegue
l’attività 1 e delega la 2 al peer A, che terminata l’esecuzione contatta il coordinatore con un
messaggio di completamento. Questa procedura avviene per tutte le attività svolte da ogni peer, in
modo che ad ogni passo il manager sia a conoscenza dello stato di avanzamento del processo
distribuito.
Figura 12 - Controllo centralizzato del processo
Questo scenario è stato applicato al caso di studio Click4aLoan per rappresentare il caso in cui
alcuni dei controlli da effettuare sulle richieste di prestito avvengano su un peer remoto, per
simulare il fatto che vi sia una agenzia apposita che esegua questi compiti, riducendo il carico di
lavoro dell’entità che ha delegato queste attività.
La figura 13 mostra l’intero flusso di processo del caso di studio Click4aLoan nel caso di controllo
centralizzato, sempre per mezzo della notazione BPMN.
47

Workflow Distribuiti Capitolo 5
Figura 13 - Controllo centralizzato applicato al caso di studio Click4aLoan
48

Workflow Distribuiti Capitolo 5
Si può notare che per ogni attività completata sul peer remoto, è necessario inviare un messaggio
al peer centrale con tutti i dati modificati durante l’attività appena conclusa in modo da consentire
al peer centrale di mantenere uno stato consistente di tutto il processo.
I peer remoti non gestiscono nessun tipo di meta-data di processo, in quanto eseguono solo
operazioni atomiche, mentre sono gestiti nella loro totalità dal peer principale, sempre con
l’obiettivo di mantenere lo stato globale di avanzamento del processo.
5.2.2. 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, è quello che inizia
il processo, e tipicamente 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 lo stato di avanzamento delle operazioni. Inoltre, ogni peer che esegue una
o più attività può delegare nuove attività agli altri peer.
Questo comporta che i meta-dati di processo sono distribuiti sui vari peer, e la traccia di
avanzamento delle attività (ad esempio, la ricerca dello stato corrente di un case) può richiedere la
consultazione di tutti i peer coinvolti.
La coordinazione dei peer può seguire dei modelli di cui riconosciamo due varianti principali:
coordinazione annidata e generalizzata.
5.2.2.1. Controllo distribuito con coordinazione annidata
La coordinazione annidata consiste nella possibilità per un peer di delegare un sotto-processo "benparentesizzato"
ad un altro peer; un sotto-processo "ben-parentesizzato" è un processo col quale
si comunica tramite un solo punto di entrata e un solo punto di uscita.
Questo scenario rappresenta il caso reale in cui un’azienda desideri delegare ad altre entità, non
operazioni atomiche, ma un’insieme di attività tra esse correlate e componenti un sotto-processo. È
facile notare come anche il peer a cui viene delegato tale sotto-processo deve essere in grado di
mantenere le informazioni necessarie ad una sua corretta gestione.
Fondamentalmente, i sotto-processi che possono essere annidati sono quelli che vengono
considerati come sequenza di attività indipendenti strutturate internamente in una gerarchia di
sotto-attività.
49

Workflow Distribuiti Capitolo 5
Deve però essere rispettata una condizione: un’eventuale diramazione del flusso di processo, deve
essere iniziata e completata all’interno dello stesso pool, ovvero il sotto-processo deve essere
portato a compimento dallo stesso utente che lo ha avviato. Nel caso in cui questo sotto-processo
venga delegato ad un altro peer, verranno quindi scambiati due soli messaggi fra i peer, uno per
avviare il sotto-processo, e uno per notificarne la terminazione.
Nella figura 14 possiamo osservare tale comportamento: solo dopo l’esecuzione delle attività 4 il
“Main Peer” viene a conoscenza dello svolgimento delle attività 2 e 3 svolte sul peer A e della 4 sul
peer B.
Figura 14 - Controllo distribuito con coordinazione annidata
La figura 15 mostra l’intero flusso di processo del caso di studio Click4aLoan nel caso di controllo
distribuito con coordinazione annidata, sempre per mezzo della notazione BPMN, e precisamente il
caso in cui vengono delegate ad un peer remoto le stesse attività dello scenario precedente, ma in
questo caso le interazioni fra i due peer avverranno solo all’avvio e al termine dei sotto-processi
delegati.
Possiamo osservare i sotto-processi "ben-parentesizzati" delegati al peer remoto e caratterizzati da
un unico punto di ingresso/uscita per quanto riguarda lo scambio dei messaggi. In questa
50

Workflow Distribuiti Capitolo 5
configurazione non è possibile, da parte del peer principale, tener traccia dello stato di tutte le
sotto-attività svolte dai peer remoti, ma verrà a conoscenza dei risultati solo alla fine
dell’esecuzione di tutte queste sotto-attività.
A differenza dell’esempio precedente, i meta-dati di workflow necessitano di essere presenti su
entrambi i peer, in quanto anche il peer remoto deve mantenere lo stato di avanzamento delle
attività a lui delegate.
Main Peer
Applicant Manager Employee
Manager
Remote Peer
Employee
Application
Request
Preliminary
Validation
Not Valid
x
x
Loan
Financial
Check
Mortgage
+
Financial
Check
Residence
Check
Job
Check
Residence
Check
+
Final
Check
Credit
Check
x
Final
Check
Final
Validation
x
Not Valid
Choice
Figura 15 - Controllo distribuito con coordinazione annidata applicato al caso di studio Click4aLoan
51

Workflow Distribuiti Capitolo 5
A differenza degli altri scenari, questo presenta due nuove attività per quanto riguarda i manager
dei peer remoti, che devono eseguire un controllo finale della attività eseguite dai rispettivi
impiegati, prima di poterne inviare i risultati al peer principale.
5.2.2.2. Controllo distribuito con coordinazione generalizzata
Con la coordinazione generalizzata, qualsiasi sottoinsieme delle attività componenti il processo può
essere delegato ad altri peer, senza sottostare a 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
interazione fra i diversi peer, deve essere scambiato un messaggio, e il loro numero può essere
molto maggiore dei due del caso precedente, in quanto si possono ottenere interazioni molto
complesse.
In figura 16 mostra un esempio semplificato del flusso di processo del caso di studio Click4aLoan
nel quale si può notare un processo “non ben-parentesizzato”: le attività Financial Check, Credit
Check e Residence Check sono delegate al peer remoto, ma a differenza degli esempi precedenti,
non è possibile identificare un unico punto di ingresso e un unico punto di uscita per il sottoprocesso
delegato.
Come si può notare dalla figura, il workflow presenta un unico punto di collegamento tra peer
principale e remoto subito dopo la validazione iniziale, ma presenta due punti di collegamento
immediatamente dopo i due controlli Financial e Residence.
Con la coordinazione generalizzata i meta-dati di processo sono ancora distribuiti su entrambi i
peer, ma il mantenimento di uno stato consistente dello stato di avanzamento delle attività e dei
processi può risultare problematico in quanto, in questo caso, è consentita l’esecuzione parallela su
diversi peer.
52

Workflow Distribuiti Capitolo 5
Main Peer
Applicant Manager Employee
Manager
Remote Peer
Employee
Application
Request
Preliminary
Validation
Not Valid
x
+
Financial
Check
Credit Check
Residence
Check
Job
Check
+
Final
Validation
x
Not Valid
Choice
Figura 16 - Controllo distribuito con coordinazione generalizzata applicato al caso di studio Click4aLoan
53

Workflow Distribuiti Capitolo 5
5.3. Interazione fra processi indipendenti
L’ultimo scenario individuato si pone su un piano differente rispetto ai precedenti, in cui vi era un
unico flusso di processo suddiviso in diversi modi fra i peer componenti il sistema.
Infatti questo scenario si occupa dell’interazione tra processi indipendenti, i quali sono a
conoscenza esclusivamente delle attività che li compongono, mentre non hanno alcuna
informazione circa il numero degli altri processi coinvolti e circa la loro struttura in termini di
attività. L’unico punto di contatto fra questi processi è rappresentato dallo scambio di messaggi a
fronte di notifiche o richieste di dati necessari al corretto svolgimento del workflow.
Può rispecchiare il caso reale in cui vi siano diverse entità che si occupano dell’esecuzione di
processi differenti l’uno dall’altro, e che necessitano di entrare in comunicazione fra loro nel
momento in cui desiderano ottenere o rendere disponibili informazioni necessarie al proseguimento
dei diversi flussi di processo.
Questo scenario non poteva essere applicato al caso di studio Click4aLoan in quanto quest’ultimo
non consente l’esecuzione di diversi flussi di processo comunicanti, essendo stato pensato come
un’unica catena di operazioni da svolgere in sequenza. Per questo motivo è stato progettato il caso
di studio Click4aCar, composto da due tipologie di flusso di processo differenti, nell’ambito della
compravendita di auto usate, e in cui è presente un’entità “concessionaria” che gestisce il flusso di
processo relativo al ciclo di vita delle auto, e diverse entità “utente” che effettuano le operazioni
legate alla loro compravendita.
Per esprimere al meglio la tipologia di interazione che comporta questo scenario, riportiamo un
diagramma, sempre in notazione BPMN, che coinvolge un processo riguardante le auto e due
processi per gli utenti:
54

Workflow Distribuiti Capitolo 5
User 1
Car
User 2
Manufacture
Matriculation
Will Sell
For Sale
Will Sell
Search Car
Purchase / Sale
Search Car
x
Usage
Demolition
Usage
Figura 17 - Interazione tra le due tipologie di workflow
Nel diagramma è rappresentato uno scenario in cui è presente un utente (User 1) che intende
vendere un’auto, interagendo con l’attività “For Sale” del flusso di processo delle auto; un secondo
utente (User 2) desidera acquistarla, ed attraverso una fase di ricerca delle auto disponibili,
procede all’acquisto; la fase “Purchase / Sale” avvisa entrambi gli utenti dell’avvenuta transazione.
Questo procedimento viene ripetuto ogni qual volta si intende eseguire una compravendita di
un’auto, eccetto nel caso in cui la concessionaria intenda ricomprare l’auto e successivamente
demolirla.
Possiamo notare come il processo relativo alle auto proceda indipendentemente dagli altri fino al
momento in cui un utente desidera acquistare o vendere un’auto, entrando in contatto con i
processi degli utenti.
In questa tipologia di distribuzione, il numero delle istanze di workflow in gioco può variare di
molto, a differenza degli scenari visti in precedenza.
55

Workflow Distribuiti Capitolo 5
Ad esempio, nel caso di studio trattato, un’ulteriore interazione possibile riguarda una istanza del
workflow relativo alle auto, e una sola istanza per gli utenti, come raffigurato in figura 18. In
questo esempio, vi è un solo utente che desidera acquistare un’auto fra quelle messe a
disposizione del concessionario, senza quindi coinvolgere un’ulteriore utente che metta in vendita la
propria auto.
Car
User
Manufacture
Matriculation
For Sale
Will Sell
Purchase / Sale
Search Car
x
Demolition
Usage
Figura 18 – Ulteriore interazione tra le due tipologie di workflow
Se da un lato, il numero di utenti coinvolti non è limitato superiormente, dall’altro questo può
anche essere nullo, come nell’esempio di figura 19, in cui viene mostrato il fatto che il flusso di
processo relativo alle auto può essere portato a conclusione anche senza interagire con un’istanza
del workflow degli utenti. Questo è possibile in quanto l’attività di demolizione richiede che il
concessionario acquisti per sé una delle auto che ha provveduto in precedenza ad immatricolare.
56

Workflow Distribuiti Capitolo 5
Figura 19 - Flusso di processo senza interazioni
57

Workflow Distribuiti Capitolo 5
5.4. Stili di progettazione
L’implementazione di workflow distribuiti implica differenti scelte progettuali, ognuna delle quali
affronta in maniera differente le difficoltà che insorgono durante la progettazione di applicazioni
Web.
Dapprima affronteremo il problema dell’assegnamento delle attività componenti il processo
distribuito. Queste possono essere assegnate da un utente sul peer principale che delega la loro
esecuzione ai peer remoti, oppure automaticamente dal sistema.
Ortogonalmente a questa problematica, si presentano due tipologie di attivazione delle attività,
nominate “push” e “pull”. Nella prima è l’utente che gestisce il workflow che decide a chi delegare
le varie attività, nella seconda sono gli utenti remoti che scelgono quale attività svolgere da una
lista di attività messa a disposizione dal peer principale. Questi scenari sono riassunti dalla
seguente tabella.
Push
Automatico
Le attività remote vengono assegnate
ai peer remoti in automatico dal
sistema
Manuale
L’assegnamento delle attività remote
è svolto da una particolare tipologia
di utente (es: manager) che ha la
visione di tutto il processo
Pull
Il sistema remoto interroga in
automatico il peer principale,
richiedendo le attività da svolgere
Gli utenti dei peer remoti gestiscono i
dati delle proprie attività, sotto il
controllo di un supervisore
(es: manager)
Analizziamo ora nel dettaglio tutte queste tipologie, identificando i diversi stili di progettazione che
le affrontano.
5.4.1. Automatico vs. Manuale
Il primo tema da affrontare riguarda l’assegnamento delle attività componenti il processo
distribuito agli utenti che successivamente si ritroveranno a svolgerle; in questo contesto si
possono identificare due approcci:
- Il primo, detto manuale, è quello in cui un utente supervisore controlla costantemente lo stato
di completamento delle attività remote e al termine di ognuna di esse assegna quella
successiva al rispettivo esecutore, delegandone poi l’esecuzione al peer remoto. Lo svantaggio
58

Workflow Distribuiti Capitolo 5
di questo approccio è che l’utente incaricato alla gestione del workflow deve regolarmente
controllare l’avanzamento del processo e delegare le attività successive, comportando il blocco
dell’esecuzione del workflow ogni qualvolta viene richiesta la sua interazione.
- Il secondo approccio è quello di rendere automatico tutto il processo di controllo e di
assegnamento delle attività remote. In questo caso il sistema al termine di un’attività remota
assegna immediatamente quella successiva e ne avvia immediatamente l’esecuzione; l’utente
entra in gioco solo alla fine della sequenza di attività remote costituenti il flusso di processo. Il
vantaggio di questa soluzione è sicuramente quello di evitare di bloccare il flusso di processo
in attesa che l’utente effettui le proprie operazioni, ma d’altro canto implica maggiori difficoltà
nel mantenere uno stato consistente di avanzamento del processo, e una minore flessibilità in
caso di errore rispetto ad un sistema supervisionato da un essere umano.
5.4.2. Push vs. Pull
La seconda dimensione da analizzare riguarda le metodologie di trasferimento delle informazioni
dal peer principale ai peer remoti circa le attività da svolgere.
- Il primo caso, denominato “push”, è quello nel quale il peer principale attraverso l’invocazione
di un Web Service pubblicato su un peer remoto, invia a quest’ultimo i dati riguardanti le
attività da eseguire, imponendogli perciò l’esecuzione di tali attività. Al termine della loro
esecuzione, il peer remoto invoca un Web Service pubblicato dal peer principale passandogli i
risultati della computazione. In questo scenario il controllo delle sottoattività e il passaggio dei
dati deve essere gestito dal peer principale, che governa il flusso delle operazioni da eseguire
ed assume una parte centralizzata in tutto il processo, sia che la prossima attività da svolgere
venga scelta manualmente, sia che avvenga in modo automatizzato.
- Il secondo scenario possibile, detto “pull” è quello in cui è il peer remoto a scegliere le attività
da eseguire fra quelle rese disponibili dal peer principale. Questo avviene tramite un Web
Service sul peer principale che pubblica i dati delle attività da svolgere remotamente. Una
volta che il peer remoto ha terminato l’esecuzione dell’attività richiama un ulteriore Web
Service che aggiorna i dati nel database del main peer. Questa soluzione implica minor
controllo da parte del peer principale, dato che non sceglie più direttamente chi esegue le
attività, ma le rende disponibili per l’eventuale esecuzione, e saranno i peer remoti a scegliere
quale eseguire e in quale momento.
Il vantaggio principale di una soluzione di questo genere, è il fatto che il peer principale non
deve essere per forza a conoscenza dell’architettura del flusso di processo riguardante i peer
remoti, ma si limita a pubblicare le attività che compongono il proprio flusso di processo.
59

Workflow Distribuiti Capitolo 5
Le difficoltà che insorgono utilizzando questa metodologia, sono dovute al fatto che il peer
principale non ha il controllo totale sull’esecuzione dei processi, e per fronteggiare questo
svantaggio, una soluzione potrebbe essere quella di aggiungere dei campi nel database per
poter tener traccia di chi ha prelevato le informazioni necessarie per poter eseguire una data
attività. Inoltre, il fatto di dover tener traccia dell’avanzamento della stessa, comporterebbe un
ulteriore scambio di messaggi, contribuendo così a complicare ulteriormente lo scenario
distribuito.
5.4.3. Assegnamento delle attività
Un’ulteriore difficoltà che insorge nell’assegnamento delle attività remote è quella relativa alla
scelta della tipologia di “assignment”: assegnare l’esecuzione delle attività ad un determinato
utente, o generarne un’istanza senza assegnare la sua esecuzione ad alcun utente.
Assegnando le attività a determinati utenti si ha il vantaggio, per il gestore del workflow, di avere
un maggior controllo sul flusso di processo, sapendo in ogni istante chi sta eseguendo una
determinata attività. Nel secondo caso invece, non vi è l’obbligo da parte del supervisore di
selezionare l’esecutore delle attività, perdendo però il controllo sulla loro esecuzione.
5.4.4. Scenari
A conclusione di questo discorso vogliamo proporre un modello esemplificativo che possa
riassumere quanto detto in precedenza.
Utente
Attività
Automatico
Manuale
Push
Pull
Questa tabella a tre dimensioni mostra tutte le combinazioni possibili dei vari stili di progettazione,
nella quale sono stati segnati con un puntino nero le soluzioni attuabili nella realtà. Come possiamo
notare tutte le combinazioni elencate possono essere realizzate, ognuna delle quali presenta
diverse difficoltà di implementazione e ha i propri vantaggi e svantaggi.
Passiamo ora ad elencare tutte queste combinazioni:
60

Workflow Distribuiti Capitolo 5
• Manuale / Utente / Push: in questa combinazione il controllo del processo è gestito
manualmente da un utente supervisore, che assegna le attività a determinati utenti
remoti che dovranno svolgerle, e che, al termine della loro esecuzione, assegnerà quelle
successive. Capiamo come, in quest’ottica, il ruolo di un supervisore sia fondamentale
sotto il punto di vista della gestione del processo, ma comporta anche il fatto che egli
debba conoscere la distribuzione degli utenti sui peer remoti.
• Manuale / Utente / Pull: in questo caso il controllo del processo è sempre gestito
manualmente da un utente supervisore, ma a differenza di quello precedente, è l’utente
remoto che preleva le attività da svolgere fra quelle a lui assegnate. Anche in questo caso
il supervisore sceglie chi eseguirà le operazioni, pubblicando le attività pronte
all’esecuzione.
• Manuale / Attività / Push: in questa combinazione il supervisore assegna le attività al
peer remoto e non ad un determinato utente, e si preoccupa di gestire tutto il processo.
Questo caso è molto simile al primo, la differenza sostanziale è che la scelta degli utenti
che svolgeranno le attività remote è delegata al peer remoto; a differenza del primo
scenario, il supervisore del peer principale non deve essere a conoscenza degli utenti
degli altri peer.
• Manuale / Attività / Pull: in questo caso è l’utente remoto che sceglie le attività da
svolgere tra quelle proposte dal peer principale, ma solo in seguito verranno assegnate ad
utenti remoti. Il supervisore sul peer principale non sa dunque chi sta eseguendo
l’attività, e nemmeno quale peer la sta eseguendo. Si comprende che in questo caso
ricostruire lo stato attuale di avanzamento del processo, comporti maggiori difficoltà
rispetto al primo caso, dato che l’eventuale richiesta deve passare tra diversi interlocutori.
• Automatizzato / Utente / Push: in questa combinazione il controllo del processo è
automatizzato, cioè il flusso di processo avviene in automatico senza verifiche da parte di
un utente supervisore: le attività vengono assegnate automaticamente dal sistema ad un
utente remoto, e al termine di un’attività componente il workflow, si effettua in
automatico l’assegnamento dell’attività successiva inviandogli poi i dati necessari. Il
supervisore, in questo caso, può limitarsi solo ad effettuare delle letture sui dati presenti
nel database per monitorare lo stato di avanzamento del processo, ma non può
controllarlo in prima persona.
• Automatizzato / Utente / Pull: come nel caso precedente, tutto il processo è
automatizzato, ma in questo scenario è l’utente remoto che si preoccupa di selezionare le
attività da svolgere tra quelle proposte dal peer principale. Per questo motivo, il livello di
61

Workflow Distribuiti Capitolo 5
difficoltà nel mantenere uno stato globale dell’avanzamento del processo è più elevato
rispetto al caso precedente.
• Automatizzato / Attività / Push: in questa combinazione il sistema assegna delle
attività ad un determinato peer, senza indicare precisamente chi dovrà eseguire le
attività. Anche in questo caso non c’è bisogno di un controllo da parte dell’utente
supervisore, dal momento che tutte le operazioni vengono eseguite in automatico
dall’applicazione.
• Automatizzato / Attività / Pull: in questo caso è il sistema remoto che si preoccupa di
selezionare le attività da svolgere tra quelle disponibili sul peer principale; questo
permette all’utente supervisore di effettuare il minor numero possibile di operazioni per la
gestione del processo, ma ciò viene pagato in termini di controllo dello stato, in quanto si
avrà maggiore difficoltà nel rintracciare lo stato attuale delle operazioni.
5.4.5. Gestione dei meta-dati
Un altro problema da affrontare riguarda la gestione dei meta-dati relativi ai workflow in uno
scenario con controllo distribuito del processo, e più precisamente nei casi in cui i sotto-processi
che lo compongono non hanno inizio e fine sullo stesso peer, comportando dei problemi circa il
mantenimento di uno stato consistente del processo da parte dei singoli peer.
In questo contesto possiamo identificare diverse soluzioni al problema:
Mantenimento globale dei meta-dati: questa soluzione prevede che tutti i peer coinvolti nella
distribuzione del processo posseggano tutti i meta-dati relativi a tutte le attività componenti il
processo, in modo tale da poter mantenere una visione completa dello svolgimento del processo sui
vari peer. Questa soluzione comporta un sostanzioso scambio di messaggi tra i vari peer per poter
sincronizzare le istanze delle varie attività, ma permette di conoscere, per ogni attività del
workflow distribuito, l’esecutore della stessa.
Per poter attuare questa soluzione, è necessario progettare le basi di dati in modo da relazionare le
istanze di attività con i peer che le eseguono, prevedendo un’entità Peer, che permetta di
identificare i peer a cui sono assegnate determinate istanze di attività, e, a sua volta, quali attività
sta svolgendo un determinato peer. Con questa soluzione è possibile effettuare facilmente richieste
sullo stato delle attività risalendo in maniera diretta ai peer che ne sono a conoscenza.
62

Workflow Distribuiti Capitolo 5
Figura 20 – Dettaglio del modello dei dati di workflow
Le informazioni contenute in questa entità possono anche essere sfruttate per poter invocare
dinamicamente i Web Services che forniscono le informazioni sullo stato delle attività, per mezzo
del campo Url.
Mantenimento parziale dei meta-dati: questa alternativa cerca di migliorare quella precedente,
prevedendo che i peer coinvolti mantengano i meta-dati di workflow solo delle “attività di confine”,
cioè quelle attività immediatamente prima o immediatamente dopo la suddivisione del processo su
due peer. Questa soluzione permette di ottenere una diminuzione dello scambio di dati, dato che le
attività “interne” (non di confine) vengono registrate solamente sul database locale di un peer.
D’altro canto non è possibile mantenere uno stato consistente di avanzamento delle operazioni: è
possibile risalire al peer che sta eseguendo le operazioni, ma la ricerca dello stato effettivo di
avanzamento delle stesse richiede una certa difficoltà, dovendo effettuare richieste distribuite sui
peer coinvolti.
Il problema fondamentale di questi approcci è la necessità di dover verificare se le applicazioni di
tutti i peer coinvolti necessitano di essere modificati a fronte dell’aggiunta o dell’eliminazione di
un’attività. Infatti, ad esempio, l’aggiunta di una nuova attività di confine comporta il cambiamento
del flusso di processo, e degli ipertesti coinvolti in questo cambiamento.
Si presenta inoltre il problema di reperire le informazioni circa lo stato di un’attività, soprattutto nel
momento in cui questa non sia di confine col peer che effettua la richiesta.
La figura sottostante mostra un esempio di processo distribuito, in cui il peer 1 è interessato allo
stato della attività 5, che è un’attività di confine dei peer 2 e 4 e non del peer 1, quindi i suoi metadati
di workflow sono residenti su questi peer. Il peer 1, in questo caso, non è nemmeno a
conoscenza del peer al quale è stata assegnata questa attività, in quanto non è una sua attività di
confine. Si potrebbe quindi adottare un algoritmo per la ricerca distribuita delle informazioni sulle
attività, la cui realizzazione esula dagli obiettivi di questo lavoro di tesi.
63

Workflow Distribuiti Capitolo 5
Figura 21 - Esempio di processo distribuito su vari peer
64

Progettazione delle applicazioni Capitolo 6
6. Progettazione delle applicazioni
65

Progettazione delle applicazioni Capitolo 6
Dopo aver presentato i vari scenari individuati nell’ambito della distribuzione dei processi, in questo
capitolo analizzeremo i diversi passi della progettazione [22] dei due casi di studio e la loro
implementazione sotto forma di diversi progetti realizzati con il CASE (Computer Aided Software
Engineering) tool WebRatio ® [25], che consente la realizzazione di applicazioni Web fortemente
basate sui dati utilizzando il linguaggio WebML, e permette la generazione automatica del codice
delle pagine che le compongono. La versione utilizzata in questo lavoro di tesi è la 3.3.7 Accademic
Pro ed il relativo Addendum per poter gestire i Workflow e i Web Services.
Per ognuno dei due casi di studio verranno presentati i requisiti dalle applicazioni, il modello dei
dati, e frammenti di ipertesto caratterizzanti i rispettivi scenari di distribuzione.
6.1. Click4aLoan
Come già introdotto nel capitolo 2.3, Click4aLoan rappresenta un’applicazione per la gestione di
prestiti bancari via Web, ed è stato utilizzato per coprire i seguenti scenari di distribuzione dei
processi:
- Nessuna distribuzione, implementato in un unico progetto denominato 1.Main.
- Distribuzione di un singolo servizio, implementato mediante due progetti separati: 2.Main,
che rappresenta l’applicazione residente sul peer principale e 2.wsProposals, che
rappresenta il servizio esportato sul peer remoto.
- Distribuzione dei sotto-processi con controllo centralizzato, costituito da tre progetti,
3.1.Main, 3.1.wsProposals, e 3.1.Remote, che rappresenta l’applicazione residente sul
peer remoto che esegue parte delle operazioni del workflow.
- Distribuzione dei sotto-processi con controllo distribuito annidato, costituito dai progetti:
3.2a.Main, 3.2a.wsProposals, e 3.2a.Remote.
- Distribuzione dei sotto-processi con controllo distribuito generalizzato, costituito dai
progetti: 3.2b.Main, 3.2b.wsProposals, e 3.2b.Remote.
Analizzeremo ora in dettaglio i requisiti delle diverse applicazioni e i rispettivi modelli dei dati. In
seguito verranno approfondite delle peculiarità di ogni scenario coperto dal caso di studio per
quanto riguarda la progettazione dell’ipertesto.
66

Progettazione delle applicazioni Capitolo 6
6.1.1. Requisiti
Introdurremo ora i requisiti fondamentali che deve rispettare la nostra applicazione divisi per
tipologia di utente. I requisiti presentati sono gli stessi per tutti e quattro gli scenari coperti dal
caso di studio, perciò verranno esposti congiuntamente.
Innanzitutto, possiamo identificare tre tipologie di attori che prendono parte al processo:
- Applicant: rappresenta l’utente che richiede il prestito attraverso il sito Web.
- Manager: rappresenta l’utente che ha il compito di supervisionare il processo di
approvazione del prestito, e che ha il compito di effettuare una validazione iniziale e una
finale.
- Employee: rappresenta l’utente che svolge i controlli di base per poter garantire il prestito
richiesto.
Per quanto riguarda l’Applicant, possiamo individuare i seguenti requisiti funzionali: la possibilità di
effettuare una ricerca delle proposte di prestito o mutuo offerte dai vari enti bancari; la possibilità
di avanzare una richiesta per un prestito o per un mutuo; poter visualizzare le richieste in corso di
approvazione, quelle approvate e quelle rifiutate; la possibilità di accettare o rifiutare il prestito o
mutuo al termine della relativa fase di approvazione.
Nel diagramma UML [8] riportato in figura 22, possiamo notare le attività che permettono di
soddisfare i requisiti emersi, e in cui si può osservare che la maggior parte delle attività eseguibili
dall’utente richiedono il riconoscimento dello stesso mediante una Login, ad eccezione della ricerca
di proposte di prestito, la quale può essere eseguita anche a titolo informativo. Per poter effettuare
la Login al sistema, l’utente deve necessariamente essere registrato. Per quanto riguarda la
richiesta di un prestito, è necessario, oltre al riconoscimento dell’utente, anche aver svolto l’attività
di ricerca di una proposta di prestito.
67

Progettazione delle applicazioni Capitolo 6
Figura 22 - Use Case Diagram per l'attore "Applicant"
Per la seconda tipologia di utente del sistema, il Manager, possiamo individuare i seguenti requisiti
funzionali: la possibilità di effettuare una validazione preliminare e una validazione finale della
richiesta avanzata dall’Applicant, e la possibilità di visualizzare i prestiti attivati.
Le attività che permettono di soddisfare questi requisiti sono riportate nel diagramma UML in
figura, dove si può notare che per eseguire le tre attività principali è necessario riconoscere l’utente
attraverso una fase di Login.
Figura 23 - Use Case Diagram per l'attore "Manager"
Per quanto riguarda l’ultima tipologia di utente, l’Employee, si possono specificare i seguenti
requisiti funzionali: la possibilità di effettuare un controllo finanziario dell’utente, un controllo della
sua occupazione, della sua residenza e della sua reputazione.
68

Progettazione delle applicazioni Capitolo 6
Nel diagramma UML riportato in figura 24, possiamo notare le attività che permettono di soddisfare
i requisiti citati, e il fatto che tutte e quattro le attività che rappresentano i controlli da effettuare
sulle richieste di prestito in corso, richiedono una preventiva fase di Login dell’impiegato.
Figura 24 - Use Case Diagram per l'attore "Employee"
6.1.2. Modello dei dati
La progettazione dei dati è un mezzo essenziale per chiarire i requisiti applicativi e produce
suggerimenti utili per la progettazione dell’ipertesto. A tal proposito, un supporto rilevante per la
definizione dello schema dei dati deriva dalla caratterizzazione delle entità che lo compongono. In
particolare possiamo identificare quattro diverse strutture nello schema Entità-Relazione:
- Oggetti Core, che costituiscono gli oggetti più importanti che l’applicazione deve gestire.
- Oggetti di interconnessione, che rappresentano le associazioni semantiche tra oggetti Core.
- Oggetti di accesso, che sono usati per classificare o specializzare gli oggetti Core.
- Oggetti di personalizzazione, utilizzati per incorporare nel modello dei dati le proprietà
rilevanti dell’utente.
Per mezzo di queste strutture, lo schema dei dati si presenta organizzato in strati ben definiti e
centrati sulle entità Core, che permette di facilitare la costruzione, la comprensione, e il
mantenimento dello stesso:
- Sotto-schema Core, che include le entità e le relazioni che denotano i concetti Core.
- Sotto-schema di accesso, che comprende le entità e le relazioni aventi il ruolo di facilitatori
di accesso.
- Sotto-schema di interconnessione, che include le relazioni che connettono le entità Core.
69

Progettazione delle applicazioni Capitolo 6
- Sotto-schema di personalizzazione, che incorpora le entità Utente e Gruppo, e le loro
associazioni con le entità Core.
Contrariamente a quanto visto per i requisiti, per il modello dei dati abbiamo diverse strutture dati
a seconda dello scenario di distribuzione implementato dal rispettivo progetto.
Per quanto riguarda le applicazioni residenti sul peer principale (indicate dal suffisso Main), ogni
progetto presenta la medesima struttura dati, che ci accingiamo ad analizzare.
Innanzitutto abbiamo individuato i seguenti oggetti Core: “Application”, “Loan Proposal” e
“Installments Plan”, i quali permettono di gestire rispettivamente i dati riguardanti le richieste di
prestito, le proposte di prestiti o mutui offerti da banche convenzionate e i relativi piani di
dilazionamento dei pagamenti.
Il passo successivo è quello di introdurre le connessioni tra i concetti Core, come, ad esempio, la
relazione che lega “Loan Proposal” con “Installments Plan”, in cui ogni proposta di prestito può
avere da zero a N piani di pagamento, mentre un singolo piano è relativo ad una sola proposta di
prestito. La seconda relazione è quella che lega “Application” con “Loan Proposal”, dove le proposte
di prestito e le relative richieste effettuate sono legate da una relazione molti-a-molti.
Il passo seguente consiste nell’aggiunta del sotto-schema di personalizzazione, che comprende le
entità che consentono di gestire i dati relativi agli utenti (registrati) del sistema, le loro relazioni
con gli oggetti Core e le regole che associano gli utenti alle site-view dell’applicazione. Le entità
coinvolte sono: “User”, che specifica i dati relativi agli utenti, “Group” che specifica le informazioni
che caratterizzano le classi di utenti con requisiti omogenei, “Site View” che permette di identificare
la site-view di riferimento per un determinato gruppo di utenti. Le relazioni che legano tali entità
sono: la relazione molti-a-molti di appartenenza di un utente a un gruppo, la relazione una-a-molti
che associa un utente ad un gruppo di default, la relazione uno-a-molti che lega le entità “Group” e
“Site View” e la relazione che lega l’entità Core “Application” con l’utente; quest’ultima relazione
associa una richiesta di prestito ad un unico utente, il quale, a sua volta, può effettuare da zero a N
richieste.
I passi descritti hanno portato alla stesura della base di dati riportata in figura 25, in cui sono stati
evidenziati i diversi sotto-schemi e la parte riguardante il meta-modello dei dati di workflow,
necessario per poter utilizzare l’estensione per i workflow di WebML.
70

Progettazione delle applicazioni Capitolo 6
Loan Proposal
OID
Amount
Company
Delay Penalty
Erogation Deadline
Erogation Method
Expenses
ID_L
Insurance Covers
Loan Type
Recess
Requirements
Xyurl
User
OID
UserName
Password
First Name
Last Name
Job Title
Email
0:N
SiteView
OID
SiteViewID
1:N
1:1
1:1 0:N Group
1:N 1:N OID
GroupName
0:N
0:N
0:N
Installments Plan
OID
Expiration
Gross Rate
ID_I
0:N
1:1
Installment Amount
Installment Number
Net Rate
Rates Details
0:N
1:1
Application
Assigned To
Executed By
OID
First Name
Last Name
Bank Account
Work
Submission Date
Credit Check
Credit Comments
Financial Check
Financial Comments
Job Check
Job Comments
Residence Check
Residence Comments
Additional Info
Additional Data
Approved
0:N
Activity Instance Status
OID
Name
0:N
0:N
1:1
Activity Instance
OID
0:N
Started
Ended
0:1
1:1
0:N
Activity
OID
Name
Description
ID
1:1
1:1
Sotto-schema “Core”
Case Status
OID
Name
0:N
1:1
Case
0:N OID
Name
Started
Ended
1:1
0:N
Process
0:N OID
Name
Description
ID
Sotto-schema di personalizzazione
Meta-modello dei dati di workflow
Figura 25 - Modello dei dati per le applicazioni residenti sul peer principale
A differenza del primo progetto, quello in cui è implementato lo scenario “nessuna distribuzione”,
quello successivo, riguardante la distribuzione di un singolo servizio, necessita di una diversa base
di dati per l’applicazione 2.wsProposals. Essa infatti rappresenta il servizio messo a disposizione da
un peer remoto che si limita ad offrire le proposte di prestito e i relativi metodi di pagamento.
Per questo motivo tale applicazione non necessita del modello dei dati presentato in precedenza
nella sua interezza, ma si limita ad utilizzarne una parte, e più precisamente le entità “Loan
Proposal” e “Installments Plan” e la relativa relazione che le associa, mentre non necessita dei
meta-dati di workflow o del sotto-schema di personalizzazione comprendente le entità riguardanti
gli utenti, i gruppi e le site-view.
Alla luce di tutto ciò, il modello dei dati per l’applicazione 2.wsProposals è quello mostrato in figura
26:
71

Progettazione delle applicazioni Capitolo 6
Figura 26 - Modello dei dati per il servizio distribuito
La distribuzione di questo semplice servizio su un peer remoto è stata mantenuta anche negli
scenari di distribuzione successivi, che quindi presentano anch’essi un’applicazione separata
denominata wsProposals.
I diversi scenari di distribuzione affrontati negli scenari successivi, introducono delle esigenze
particolari che vengono rispecchiate da differenze nel modello dei dati dell’applicazione residente
sul peer-remoto, e più in particolare per quanto riguarda gli scenari di distribuzione dei sottoprocessi
con controllo centralizzato, distribuito annidato e distribuito generalizzato. Per quanto
concerne lo scenario “distribuzione dei sotto-processi con controllo centralizzato”, non vi è la
necessità per l’applicazione residente sul peer remoto (3.1.Remote) di mantenere i meta-dati di
workflow e di tenere traccia dello stato di esecuzione delle attività svolte su quel peer, essendo
esse atomiche; per questo il suo modello dei dati non presenta le relative entità, ma comprende
solamente il sotto-schema di personalizzazione e l’entità relativa alle richieste di prestito in corso,
come possiamo notare dalla figura 27:
Figura 27 - Modello dei dati per l'applicazione 3.1.Remote
72

Progettazione delle applicazioni Capitolo 6
Per quanto riguarda invece gli ultimi due scenari, “Distribuzione dei sotto-processi con controllo
distribuito annidato” e “Distribuzione dei sotto-processi con controllo distribuito generalizzato”,
l’applicazione residente sul peer remoto ha la necessità di mantenere i meta-dati di workflow, per
questo il modello dei dati estende quello precedente con le entità e le relazioni appropriate:
Figura 28 - Modello dei dati per i progetti 3.2aRemote e 3.2bRemote
73

Progettazione delle applicazioni Capitolo 6
6.1.3. Ipertesto
La progettazione dell’ipertesto ha origine da tre sorgenti di input: lo schema concettuale dei dati,
che esprime la struttura dei dati, i requisisti funzionali, che indicano le funzionalità che devono
essere fornite dall’applicazione, e le mappe delle site-view, che delineano l’organizzazione degli
ipertesti che devono essere offerti agli utenti.
Presenteremo ora un riepilogo essenziale per quanto riguarda le site-view che compongono i diversi
progetti, per poter fornire un quadro generale della struttura delle applicazioni. Non ci
soffermeremo dettagliatamente su tutti i passi della loro progettazione, ma tratteremo nel
particolare le porzioni di ipertesto che consentono la realizzazione dei diversi scenari di
distribuzione precedentemente analizzati, corredandoli con esempi di implementazione nel CASE
tool WebRatio ® .
6.1.3.1. Organizzazione delle site-view
L’organizzazione delle site-view, e il loro contenuto navigazionale, cambia in base alla tipologia di
applicazione (Main, Remote o wsProposals) e in base allo scenario di distribuzione implementato,
per questo motivo provvederemo a fornire una visione generale delle site-view componenti i vari
progetti ed una descrizione del loro contenuto:
Scenario 1: Nessuna distribuzione
o 1.Main: composto dalle site-view: “Public Site View”, che permette ad un utente di
effettuare una ricerca delle proposte di prestito, registrarsi al sistema, ed effettuare la
login; “Manager Site View”, che consente al manager di effettuare le attività “Preliminary
Validation” e “Final Validation”; “Employee Site View”, che permette all’impiegato di
eseguire i quattro controlli relativi alla richiesta di prestito (Financial, Residence, Credit e
Job Check); “Applicant Site View”, che consente all’utente registrato di effettuare una
richiesta di prestito, di accettare o rifiutare il prestito al termine della fase di validazione, e
di visualizzare lo stato delle proprie richieste.
Scenario 2: Distribuzione di un singolo servizio
o 2.Main: composto dalle medesime site-view dello scenario precedente, ma nella “Public
Site View” l’ipertesto permette di ottenere i dati relativi alle proposte di prestito da un Web
Service remoto.
74

Progettazione delle applicazioni Capitolo 6
o
2.wsProposals: che rappresenta il servizio remoto ed è composto dalla site-view “Remote
Loan Proposals”, in cui il layout di pagina è impostato su “SOAP Envelope” per permettere
all’applicazione di generare file di configurazione SOAP al posto di pagine JSP, ed è
selezionato lo stylesheet “Web services” per poter generare documenti XML al posto di
pagine HTML.
Scenario 3.1: Distribuzione dei sotto-processi con controllo centralizzato
o 3.1.Main: composto dalle stesse site-view dei progetti “Main” precedenti, le uniche
differenze si riscontrano nelle site-view: “Manager Site View”, in cui il manager, oltre alle
validazioni iniziale e finale, deve occuparsi della gestione della comunicazione col peer
remoto e assegnare le attività agli utenti remoti, in quanto è stato implementato lo
scenario “Manuale / Attività / Push”, come descritto nel capitolo 5.4.4; “Employee Site
View”, in cui l’impiegato svolge solo l’attività “Job Check”, essendo le altre attività delegato
al peer remoto. Per questo motivo, questo progetto presenta un’ulteriore site-view
denominata “Web Service” che contiene le unit che permettono lo scambio di dati dal peer
remoto verso il peer principale.
o 3.1.wsProposals: che presenta le medesime caratteristiche del progetto 2.wsProposals.
o 3.1.Remote: che rappresenta l’applicazione residente sul peer remoto, ed è composta
dalle site-view: “Public Site View”, che permette agli impiegati remoti di effettuare la login
al sistema; “Employee Site View”, che consente loro di effettuare i tre controlli (Financial,
Residence e Credit Check) sulle richieste di prestito; “Web Service”, con layout di pagina
“SOAP Envelope” e stylesheet “Web services”, che permette la ricezione delle attività da
svolgere da parte del peer principale.
Scenario 3.2a: Distribuzione dei sotto-processi con controllo distribuito annidato
o 3.2a.Main: composto dalle stesse site-view del progetto 3.1.Main, varia però l’ipertesto
per la gestione del flusso di processo.
o 3.2a.wsProposals: che presenta le medesime caratteristiche del progetto 2.wsProposals.
o 3.2a.Remote: composto medesime site-view del progetto 3.1.Remote, a cui viene
aggiunta la site-view “Manager Site View”, che consente al manager del peer remoto di
assegnare agli impiegati le attività delegate dal peer principale e di restituire le
informazioni elaborate al termine delle attività degli impiegati stessi.
75

Progettazione delle applicazioni Capitolo 6
Scenario 3.2b: Distribuzione dei sotto-processi con controllo distribuito generalizzato
o 3.2b.Main: composto dalle stesse site-view del progetto 3.1.Main, varia però l’ipertesto
per la gestione del flusso di processo, ed in particolare nella “Employee Site View”, in cui
l’impiegato, oltre ad effettuare l’attività “Job Check”, deve anche gestire le informazioni
ricevute dal peer remoto.
o 3.2b.wsProposals: che presenta le medesime caratteristiche del progetto 2.wsProposals.
o
3.2b.Remote: composto dalle site-view viste nel 3.2b.Remote, la differenza principale
rispetto allo scenario precedente riguarda l’ipertesto che invia le informazioni elaborate al
termine delle attività, che è posizionato nella “Employee Site View”, in quanto la
comunicazione col peer principale non è gestita unicamente dal manager.
6.1.3.2. Implementazione degli scenari di distribuzione
La progettazione dell’ipertesto è influenzata notevolmente dalla distribuzione del processo, in
quanto le applicazioni Web sono suddivise fra i vari peer coinvolti, seguendo i modelli di interazione
presentati in precedenza.
Riporteremo ora dei frammenti di ipertesto che ci permettono di far comprendere come è possibile
integrare la distribuzione dei processi nel design dell’ipertesto di un’applicazione Web attraverso il
linguaggio WebML e le sue estensioni per i Workflow e per i Web Service.
I vari scenari saranno integrati con delle catture del CASE tool WebRatio ® , con il quale sono state
realizzate le applicazioni, e le relative pagine Web generate, che verranno poi navigate dagli utenti.
76

Progettazione delle applicazioni Capitolo 6
Distribuzione di un singolo servizio
Il caso più semplice di distribuzione è l’invocazione di un servizio semplice pubblicato da un peer
remoto. Questo scenario è quello implementato dai progetti 2.Main e 2.wsProposals. Per quanto
riguarda la loro interazione, vengono utilizzate esclusivamente le primitive per la pubblicazione e
l’invocazione di Web Service fornite da WebML.
In figura 29 possiamo osservare il frammento di ipertesto necessario per la pubblicazione del
servizio remoto, incluso nella site-view “Remote Loan Proposals” del progetto 2.wsProposals;
mentre in figura 30 è riportato l’ipertesto necessario alla sua invocazione, incluso nella site-view
“Public Site View” del progetto 2.Main:
Figura 29 - Pubblicazione del servizio remoto “getAllLoansAndInstallments”
Attraverso una Hierarchical Index Unit (Loans Index), è possibile recuperare dalla base di dati
remota tutte le proposte di prestito e i relativi metodi di pagamento, e pubblicarli per mezzo della
Solicit-Response Unit (getAllLoansAndInstallments). Il nome del servizio pubblicato sarà quindi
“getAllLoansAndInstallments”.
Figura 30 - Invocazione del servizio remoto “getAllLoansAndInstallments”
Per poter invocare il servizio pubblicato, sul peer principale viene utilizzata una Request-Response
Unit (Read Loans). I passi che la seguono permettono di inserire i dati letti in un database virtuale
attraverso una trasformazione XSL iniziale, realizzata mediante un’Adapter Unit (Adapter Loan) e il
77

Progettazione delle applicazioni Capitolo 6
relativo file XSL adapt_LOAN-INSTALLMENTS.xsl, ed una successiva conversione in un formato
relazionale tramite una unit XML In. È così possibile, tramite delle Index e delle Data Unit,
recuperare i dati contenuti nella base di dati virtuale, e proseguire nella navigazione dell’ipertesto.
La figura 31 mostra l’implementazione nel CASE tool WebRatio ® dell’area “Proposal” appartenente
alla site-view “Public Site View”, nella quale possiamo notare le unit necessarie all’invocazione del
servizio remoto che fornisce le proposte di prestito e i piani di pagamento. Dalla pagina “Loan
Index”, il richiedente può selezionare quella desiderata e procedere con la richiesta tramite il link
“Choose This Installment". La figura 32 mostra invece la pagina come viene visualizzata all’utente.
Figura 31 - Schermata del tool WebRatio ® relativa all'area "Proposals"
78

Progettazione delle applicazioni Capitolo 6
Figura 32 - Pagina "Loan Index"
Possiamo notare in figura 31, che alcune Data Unit dell’ipertesto hanno come entità di riferimento
“TextChunk”; questa entità è stata introdotta per poter memorizzare nella base di dati delle
informazioni da presentare all’utente a livello di presentazione per migliorare la sua interazione col
sistema, fornendo suggerimenti testuali relativi alle operazioni da effettuare; la loro presenza non
ha alcuna influenza sul flusso di processo.
79

Progettazione delle applicazioni Capitolo 6
Push vs. Pull
Come presentato nel capitolo 5.4.2, si possono individuare due metodologie di trasferimento delle
informazioni dal peer principale ai peer remoti, comuni a tutti gli scenari di distribuzione.
Per quanto riguarda la modalità “Push”, il peer principale invoca un Web Service pubblicato dal
peer remoto inviandogli i dati riguardanti le attività da eseguire, imponendo perciò al peer remoto
l’esecuzione di tali attività; al termine dell’esecuzione, quest’ultimo invoca un Web Service
pubblicato dal peer principale passandogli i risultati della computazione. In questo scenario il
controllo delle sottoattività e il passaggio dei dati viene gestito dal peer principale, che governa il
flusso delle operazioni ed assume una parte centralizzata in tutto il processo.
Figura 33 - Modello concettuale del trasferimento di informazioni in modalità "Push"
L’ipertesto necessario alla pubblicazione dei Web Services atti a ricevere le informazioni riguardanti
le attività da svolgere e i dati di ritorno dal peer remoto è quello presentato in figura 34; per
quanto riguarda la loro invocazione, il frammento di ipertesto è rappresentato unicamente da una
Unit Request-Response, la quale mediante la trasformazione XSL adatta, permette di inviare i dati
necessari e associarli correttamente ai parametri di ingresso delle rispettive unit Solicit-Response:
Figura 34 - Ipertesto per la pubblicazione di un servizio per la ricezione di dati
80

Progettazione delle applicazioni Capitolo 6
La seconda modalità, detta “Pull”, è quella in cui è il peer remoto a richiedere al peer principale le
attività da eseguire. Questo è possibile grazie ad un Web Service pubblicato dal peer principale che
rende disponibili i dati delle attività da svolgere remotamente. Una volta che il peer remoto ha
terminato l’esecuzione dell’attività scelta, richiama un ulteriore Web Service attraverso il quale è
possibile aggiornare i dati nel database del peer principale. Questa soluzione implica minor
controllo da parte del peer principale, dato che non è a conoscenza degli esecutori delle attività, ma
le rende disponibili per la loro esecuzione; saranno quindi i peer remoti a scegliere le attività da
eseguire e il momento in cui eseguirle.
Per comprendere al meglio questo scenario, riportiamo ora uno schema concettuale dello
svolgimento delle operazioni, ed in seguito la porzione di ipertesto che sul peer principale si occupa
della pubblicazione delle attività da eseguire, e quella che aggiorna i dati al termine delle attività
eseguite sul peer remoto.
Figura 35 - Modello concettuale del trasferimento di informazioni in modalità "Pull"
L’ipertesto in figura 36 mostra la pubblicazione delle attività da eseguire remotamente, lo stesso
ipertesto viene utilizzato per pubblicare i risultati dell’esecuzione delle attività.
Figura 36 - Frammento di ipertesto per la pubblicazione delle attività da svolgere remotamente
81

Progettazione delle applicazioni Capitolo 6
In figura 37 è riportato il frammento di ipertesto necessario per l’invocazione dei Web Service
pubblicati, che permette di inserire nel database del peer remoto i dati sulle attività da svolgere, e
al peer principale di scrivere nella propria base di dati i risultati dell’esecuzione di tali attività.
Figura 37 - Ipertesto per l'aggiornamento dei dati a fronte dell'invocazione di un Web Service
In figura possiamo notare la unit Request-Response, la quale attraverso un’appropriata
trasformazione XSL, fornisce i dati letti dal Web Service ad una XML In Unit, che provvederà ad
aggiornare il database reale del peer coinvolto.
Le difficoltà che insorgono utilizzando questa metodologia, sono dovute al fatto che il peer
principale non ha il controllo totale dell’esecuzione delle attività; per questo motivo sarebbe
opportuna l’aggiunta di particolari accorgimenti nella base di dati per poter tener traccia di colui
che ha prelevato i dati per l’esecuzione di una data attività. Inoltre per tener traccia
dell’avanzamento delle attività, e per evitare che essa venga eseguita più volte, sarebbe necessario
un ulteriore scambio di messaggi, con relativa pubblicazione e invocazione di Web Services,
contribuendo cosi a complicare ulteriormente lo scenario distribuito.
Entrambe le metodologie di trasferimento delle informazioni, non sono legate ad un particolare
scenario di distribuzione, ma possono essere adottate in tutti i casi in cui occorre scambiare
informazioni fra diversi peer; infatti per quanto riguarda i casi di studio implementati, è stata
adottata per tutti i progetti relativi a Click4aLoan la modalità Push per l’invio dei dati sulle attività
da eseguire sui peer remoti, mentre per l’applicazione Click4aCar, è stata utilizzata la modalità Pull
per quanto riguarda la ricerca di auto in vendita da parte di un utente, e la modalità Push per la
conferma di acquisto e la messa in vendita di un’auto.
Distribuzione dei sotto-processi con controllo centralizzato
Come descritto nei capitoli precedenti, il flusso di processo di questo scenario, prevede la delega
dell’esecuzione di alcune attività a peer remoti, i quali eseguono solamente queste attività
atomiche. Il peer principale, l’unico a gestire i meta-dati di workflow, dovrà governare anche quelli
riferiti a queste attività, anche se poi verranno eseguite su un altro peer. La soluzione adottata è
quella di avviare l’attività sul peer principale prima di inviare i dati al peer remoto, e terminarla al
82

Progettazione delle applicazioni Capitolo 6
ricevimento dei dati risultanti da quest’ultimo. In figura 38 è riportato uno schema concettuale che
mostra la soluzione adottata.
Figura 38 - Schema concettuale della gestione delle attività remote
Il problema che insorge consiste nell’assegnamento di tali attività, in quanto, non mantenendo i
peer remoti i meta-dati di workflow, non sarà loro possibile sfruttare le potenzialità offerte dalle
unit per i workflow di WebML per quanto riguarda l’esecuzione delle attività. Una soluzione è quella
di assegnare queste attività all’utente che gestisce il flusso di processo sul peer principale, e più in
particolare al manager, ed avviare e terminare le attività sul peer principale, mentre la loro
effettiva esecuzione avviene sui peer remoti.
Partendo da questa premessa, affrontiamo ora il problema della distinzione tra controllo automatico
e manuale del flusso di processo, che comporta differenze sostanziali per quanto riguarda
l’ipertesto dell’applicazione del peer principale; analizzeremo ora le due soluzioni.
Per quanto riguarda lo scenario del controllo manuale del flusso di processo, il manager ha il
compito di intervenire attivamente ad ogni interazione col peer remoto, controllando se l’attività
remota ha avuto termine e di conseguenza avviare l’attività successiva.
In particolare mostreremo la porzione del processo che va dall’avvio della prima attività “Financial
Check” fino al termine della seconda attività “Residence Check”, la quale ci permetterà di
comprendere le scelte progettuali adottate, e che abbiamo evidenziato nel seguente diagramma del
flusso di processo, descritto attraverso la notazione BPMN.
83

Progettazione delle applicazioni Capitolo 6
Figura 39 - Porzione del processo analizzata
Riportiamo ora i frammenti di ipertesto relativi alla porzione di flusso di processo in esame, che ci
consentiranno di comprendere come è possibile implementare uno scenario di distribuzione di
questo tipo.
La figura 40 mostra l’ipertesto della site-view “Manager Site View” dell’applicazione residente sul
peer principale. Esso inizia con la pagina Remote Financial Check, da cui il manager può selezionare
una delle attività “Financial Check” a lui stesso assegnate in seguito ad una validazione iniziale, per
mezzo di una Workflow Index Unit, avviando così l’attività scelta attraverso una Start Unit. Il passo
successivo, invisibile all’utente, consiste nell’invocare un Web Service pubblicato dal peer remoto,
inviandogli i dati relativi all’attività da svolgere. L’implementazione di questo servizio sul peer
remoto è mostrato in figura 41, dove si può notare una Solicit-Response Unit che riceve i dati dal
peer principale, ed inserisce nella base di dati remota una nuova istanza con i dati ricevuti.
84

Progettazione delle applicazioni Capitolo 6
Figura 40 - Frammento di ipertesto della site-view “Manager Site View” del peer principale
Figura 41 - Web Service per la ricezione dei dati dal peer principale
A questo punto, come mostrato nella figura 42, gli impiegati del peer remoto, attraverso una Index
Unit, possono visionare le attività da eseguire e svolgere le operazioni necessarie, dopodichè
invieranno i risultati del loro lavoro al peer principale attraverso una One Way Unit (Return Data),
che invocherà un Web Service pubblicato da quest’ultimo, che provvederà ad aggiornare i dati
relativi alla richiesta di prestito per la quale è stata eseguita l’attività di controllo finanziario.
L’ipertesto per la realizzazione del Web Service in questione è riportato in figura 43, in cui vengono
modificati i dati della richiesta di prestito in esame con i dati provenienti dal peer remoto.
85

Progettazione delle applicazioni Capitolo 6
Figura 42 - Frammento di ipertesto della site-view "Employee Site View" sul peer remoto
Figura 43 - Web Service per la ricezione dei dati dal peer remoto
Una volta aggiornate le informazioni nella base di dati del peer principale, esse verranno mostrate
al manager tramite una Index Unit, il quale potrà così confermarne la ricezione e far proseguire il
flusso di processo, assegnando nuovamente a se stesso l’attività successiva “Residence Check”, e
terminando così l’attività “Financial Check”. Il manager, a questo punto, potrà selezionare la
successiva attività “Residence Check” e ripetere l’interazione descritta in precedenza per l’attività
“Financial Check”. Lo stesso procedimento avverrà anche per l’attività “Credit Check”, eseguita a
valle dei controlli precedenti. Al termine dell’ultimo controllo, verrà assegnata al manager l’attività
“Final Validation”, tramite la quale il manager verificherà i risultati di tutti i controlli effettuati dagli
impiegati e deciderà se concedere o meno il prestito.
Dal momento che WebML non prevede la notifica all’utente dell’arrivo di dati da parte di un altro
peer, è stato necessario adottare la seguente strategia: il manager per verificare la ricezione dei
dati da parte del peer che ha eseguito l’attività, deve effettuare diversi refresh della pagina
“Financial Check Status”, mediante il relativo link, in modo da permettere la visualizzazione delle
informazioni modificate nella base di dati dal Web Service “Return Data”. Solo a questo punto
apparirà il link per consentire la prosecuzione del flusso di processo con l’attività successiva.
La figura seguente riporta una schermata del tool WebRatio ®
che mostra l’area “Remote Loan
Checks Area” appartenente alla site-view “Manager Site View” dell’applicazione sul peer principale,
la quale gestisce le interazioni con i peer remoti per quanto riguarda le richieste di prestiti, e dove
si può notare la strategia precedentemente descritta.
86

Progettazione delle applicazioni Capitolo 6
Figura 44 - Schermata del tool WebRatio ® relativa all'area " Remote Loan Checks Area "
87

Progettazione delle applicazioni Capitolo 6
In quest’area sono presenti diverse pagine “landmark”, che rappresentano le pagine di “refresh”
(Remote Financial Check Status, Remote Residence Check Status, Remote Credit Check Status), le
quali permettono al manager di controllare l’arrivo delle informazioni riguardanti il controllo
corrispondente effettuato sui peer remoti, e di proseguire così nel flusso di processo. Queste pagine
sono “landmark” per poter essere raggiunte in qualsiasi momento da parte del manager che,
mentre attende i dati dai peer remoti, può dedicarsi ad altre attività.
La parte finale delle operazioni mostrate in figura 42 consiste nell’effettuare diversi test per poter
controllare la terminazione delle attività precedenti ed assegnare la successiva attività “Final
Validation”.
Nella figura 45 è riportata la pagina “Remote Financial Check Status” visualizzata dal manager,
nella quale è possibile notare il link di refresh “Check Remote Status”, con il quale è possibile
controllare l’arrivo dei dati per il controllo finanziario; una volta che questi saranno disponibili,
verrà visualizzata la richiesta di prestito corrispondente nell’area “Loan Requests”; una volta
selezionata porterà il manager nella pagina in cui convalidare la ricezione dei dati, e portare avanti
così il flusso di processo.
Figura 45 - Pagina "Remote Financial Check Status" dell’applicazione 3.1.Main
Per quanto riguarda invece lo scenario del controllo automatico del flusso di processo, il manager
non deve intervenire attivamente ad ogni interazione col peer remoto, ma sarà il sistema che
assegnerà, avvierà e terminerà in maniera automatica le attività remote.
88

Progettazione delle applicazioni Capitolo 6
Questo procedimento composto dall’assegnamento della prossima attività da eseguire
remotamente, dalla terminazione dell’attività precedente, dall’avvio di quella successiva e dall’invio
dei dati al peer remoto, ha concettualmente la struttura riportata in figura 46.
Web Service (Main Peer)
Return Data
Modify
Assign Unit End Unit Start Unit
OK OK OK OK
Request Remote
Check
Application
Residence Check
Financial Check
Residence Check
Figura 46 - Frammento di ipertesto per il controllo automatico del flusso di processo
Questa soluzione, anche se può sembrare più semplice rispetto al procedimento descritto in
precedenza, dal punto di vista implementativo presenta delle difficoltà dovute al CASE tool
WebRatio ® ; essendo la sequenza di ipertesto da implementare situata nella siteview “Web Service”
che prevede l’utilizzo di un layout di pagina e di uno stylesheet particolari, non vi è la possibilità
per le unit coinvolte di accedere ai dati necessari alla loro corretta esecuzione.
89

Progettazione delle applicazioni Capitolo 6
Distribuzione dei sotto-processi con controllo distribuito annidato
Questo scenario prevede la delega ai peer remoti da parte del peer principale di sotto-processi benparentesizzati,
composti da una serie di attività, e non più di attività atomiche come nel caso
precedente.
Il peer principale non deve gestire la serie di attività che compongono il flusso del sotto-processo
delegato al peer remoto, vedendolo come una “black-box”, di cui conosce solamente l’unico punto
di uscita e l’unico punto di ingresso.
La soluzione implementativa da noi introdotta riguarda il fatto di rappresentare, sul peer principale,
tale sotto-processo come un’unica attività; questa sarà dapprima assegnata al manager del peer
principale, avviata prima dell’invio dei dati al peer remoto, e terminata al momento della ricezione
dei risultati della computazione.
Nella figura successiva verrà riportato un esempio della soluzione introdotta.
Figura 47 - Schema concettuale della gestione del sotto-processo delegato ai peer remoti
90

Progettazione delle applicazioni Capitolo 6
Ad esempio, per quanto riguarda il sotto-processo evidenziato in figura 48, esso sarà identificato
dal peer principale come un’unica attività “Remote Check”.
Figura 48 – Sotto-processo “ben-parentesizzato”
In figura 49 è riportato un frammento dell’ipertesto della site-view del manager del peer principale,
che consente la realizzazione dello scenario in esame. Esso inizia con il click da parte del manager
del link “Start Remote Process” al termine della validazione iniziale, che porterà all’assegnamento
dell’attività “Remote Check” al manager stesso, e alla successiva terminazione dell’attività di
validazione iniziale. A questo punto verranno presentate al manager le richieste di prestito che
hanno superato la validazione iniziale; selezionandone una si darà avvio all’attività “Remote Check”
e all’invio dei dati necessari al peer remoto.
Il flusso navigazionale del manager continua nella pagina “Remote Check Status”, la quale presenta
un link di refresh, come per il caso precedente, che permette, una volta ricevuti i risultati della
91

Progettazione delle applicazioni Capitolo 6
computazione dal peer remoto, di procedere con l’assegnamento della successiva attività di “Final
Validation” e di terminare l’attività “Remote Check”.
Manager Site View (Main Peer)
Preliminary Validation
Page
Remote Validation
Start Remote Process
Assign Unit
OK
End Unit
OK
Remote Check
Start Unit
OK
Request Remote
Check
Remote Check
Preliminary Validation
Application
Remote Check
End Unit
Assign Unit
Remote Check Status
Index unit
OK
Remote Check
Final Validation
Application
[Additional Info =
RemChk_ok]
Figura 49 - Frammento di ipertesto della site-view "Manager Site View" sul peer principale
Per quanto riguarda il peer remoto, esso pubblica un Web Service per ricevere i dati dal peer
principale, e richiede al manager di assegnare le attività componenti il sotto-processo agli impiegati
che poi le eseguiranno. Al termine della loro esecuzione, il manager controllerà i dati risultanti e li
invierà al peer principale attraverso l’invocazione di un Web Service pubblicato da quest’ultimo.
A differenza dello scenario con controllo centralizzato, il peer principale non è in grado di conoscere
l’effettivo stato di avanzamento del sotto-processo delegato ai peer remoti, in quanto non conosce
le attività che lo compongono; ne verrà a conoscenza solo nel momento in cui verrà notificato della
fine della computazione da parte del peer remoto.
In figura 50 possiamo notare come è stato implementato nel tool WebRatio ®
l’ipertesto appena
descritto, e più precisamente una porzione dell’area “Manager Area” nella quale è presente il
frammento di ipertesto che delega i sotto-processi al peer remoto, e l’area “Remote Loan Check
Area” nella quale il manager può controllare lo stato di ricezione dei dati al termine dell’esecuzione
del sotto-processo delegato per quanto riguarda le richieste di prestiti semplici e proseguire poi nel
flusso di processo. Quest’ultima area è definita come “landmark” per poter essere raggiunta da
qualsiasi punto della navigazione, lasciando il manager libero di eseguire altre operazioni in attesa
dei dati dai peer remoti.
In figura 51 è riportata la pagina che si presenterà al manager e dalla quale può selezionare la
richiesta di prestito desiderata ed inviare i relativi dati al peer remoto.
92

Progettazione delle applicazioni Capitolo 6
Figura 50 - Schermata del tool WebRatio ® relativa alle aree "Manager Area" e “Remote Loan Check Area”
Figura 51 - Pagina "Remote Validation" dell’applicazione 3.2a.Main
93

Progettazione delle applicazioni Capitolo 6
Distribuzione dei sotto-processi con controllo distribuito generalizzato
A differenza dello scenario precedente, non è possibile identificare un unico punto di ingresso e
uscita per quanto riguarda il sotto-processo delegato ai peer remoti, e per questo motivo il sottoprocesso
viene detto “non ben-parentesizzato”. L’ipertesto viene influenzato pesantemente da
questa situazione, di seguito presenteremo le differenze rispetto allo scenario precedente,
esaminando il sotto-processo evidenziato in figura 52.
Main Peer
Applicant Manager Employee
Manager
Remote Peer
Employee
Application
Request
Preliminary
Validation
Not Valid
x
+
Financial
Check
Credit Check
Residence
Check
Job
Check
+
...
Figura 52 - Sotto-processo non “ben-parentesizzato”
Innanzitutto non è più possibile per il peer principale riassumere le attività remote come un’unica
attività generica, in quanto non essendoci un unico punto di ritorno, non è possibile gestire
correttamente la terminazione della suddetta attività, e di conseguenza proseguire con il flusso di
processo.
94

Progettazione delle applicazioni Capitolo 6
La soluzione adottata nella progettazione dell’ipertesto consiste nell’introduzione nel flusso di
processo del peer principale di attività corrispondenti alle attività di confine del peer remoto, le
quali rappresentano quelle attività che si posizionano esattamente dopo ed esattamente prima la
ricezione e l’invio dei dati al peer principale, come mostrato nello schema concettuale riportato
nella figura seguente:
Figura 53 - Schema concettuale per il controllo del sotto-processo "non ben-parentesizzato"
Tale soluzione permette di tener traccia nella base di dati, grazie ai meta-dati di workflow di
WebML, dell’avanzamento del flusso di processo, e più in particolare del fatto di aver delegato
l’esecuzione di una sua parte ad un altro peer. Il vantaggio sostanziale, però, si verifica al
momento della ricezione dei dati di ritorno dai peer remoti; per esempio, come nel caso trattato,
95

Progettazione delle applicazioni Capitolo 6
essendoci due messaggi in ingresso al peer principale, non sempre è possibile identificare quale
attività è stata terminata.
Dal punto di vista implementativo, la gestione da parte del peer principale di queste nuove attività,
si differenzia nel caso in cui esse vengano attivate al momento dell’invio di un messaggio o al
momento della sua ricezione. Per quanto riguarda l’invio dei dati al peer remoto, l’ipertesto
utilizzato sarà quello in figura 54:
Figura 54 - Ipertesto per il caso di invio di un messaggio al peer remoto
Il peer principale, con tale struttura ipertestuale ha la possibilità di avviare l’attività corrispondente
all’attività di confine appartenente al peer remoto prima dell’invio dei dati e terminarla subito dopo,
in quanto non è prevista l’esecuzione di altre operazioni all’interno di essa. Questo ci permette di
avere nella base di dati una traccia della delega di un sotto-processo ad un altro peer, in quanto,
senza la sua introduzione, non sarebbe possibile riconoscere lo stato di avanzamento dell’intero
processo.
Per quanto riguarda l’esempio implementato, non è presente sul peer remoto una vera e propria
attività di confine immediatamente dopo la ricezione del messaggio inviato dal peer principale, in
quanto il sotto-processo inizia direttamente con una diramazione; per questo motivo l’attività
corrispondete sul peer principale è stata chiamata “Remote Check”.
Figura 55 - Ipertesto per il caso di ricezione di un messaggio dal peer remoto
Per quanto riguarda la ricezione dei dati da parte del peer principale, l’ipertesto suggerito è quello
riportato in figura 55, in cui a fronte della ricezione dei dati, viene avviata un’attività
corrispondente all’ultima attività (di confine) svolta dal peer remoto prima dell’invio del messaggio;
96

Progettazione delle applicazioni Capitolo 6
in seguito verranno apportate le modifiche necessarie alla base di dati, assegnata l’attività
successiva e infine eseguita la End Unit.
Il vantaggio ottenibile da una soluzione di questo genere, oltre al fatto di tener traccia dello stato di
avanzamento del processo, è quello di poter controllare l’effettivo completamento delle attività
remote, per poter proseguire nel flusso di processo, mediante l’utilizzo di una semplice “Get
Activity Status Unit”. Per quanto riguarda l’esempio implementato, questa soluzione ci permette di
verificare la ricezione di entrambi i messaggi di ritorno dal peer remoto e di conseguenza
proseguire col flusso di processo.
In figura 56 è riportato l’ipertesto utilizzato nel progetto 3.2b.Main per eseguire il controllo
dell’effettiva ricezione di entrambi i messaggi di ritorno, con gli accorgimenti necessari per poter
sopperire al fatto che non è possibile, al momento, posizionare le unit mostrate in figura 55 in una
site-view predisposta per la pubblicazione di Web Service.
Figura 56 - Frammento di ipertesto della site-view "Employee SIte View" sul peer principale
Possiamo notare che tramite una Workflow Index Unit, l’impiegato sul peer principale può visionare
le richieste di prestito di cui sono stati ricevuti i dati inviati dal peer remoto al termine dell’attività
“Residence Check” da lui eseguita. Dopo aver selezionato la richiesta desiderata viene avviata
l’attività “Remote Residence Check”, corrispondente all’attività di confine “Residence Check”; in
seguito verrà eseguito il controllo dello stato dell’attività “Job Check”, eseguita subito dopo la
ricezione dei dati riguardanti l’attività remota “Financial Check” e implementata in un altro
frammento di ipertesto; se lo stato di questa attività è “Completed” è possibile eseguire
l’assegnamento della successiva attività “Final Validation” che sarà eseguita dal manager. La
terminazione dell’attività “Remote Residence” può avvenire o dopo l’assegnamento dell’attività
successiva, oppure a valle della Test Unit, nel caso in cui non sia stata ancora completata l’attività
97

Progettazione delle applicazioni Capitolo 6
“Job Check”; sarà quindi l’ipertesto riguardante questa fase che controllerà l’effettiva terminazione
dell’attività “Remote Residence Check” e assegnerà al manager l’attività “Final Validation”.
La soluzione proposta può essere adattata per soddisfare tipologie di divisione del flusso di
processo differenti rispetto a quella da noi implementata, con, ad esempio, un numero variabile di
punti di uscita e ingresso del sotto-processo.
Un ulteriore approccio sarebbe stato quello di mantenere sul peer principale delle attività “fittizie”
corrispondenti a tutte le attività delegate al peer remoto, questo permetterebbe di mantenere
costantemente sotto controllo l’effettivo stato di avanzamento del processo, ma d’altro canto
comporterebbe uno scambio massiccio di messaggi fra i due peer.
Per quanto riguarda l’implementazione nel tool WebRatio ® , in figura 57 è riportato il frammento di
ipertesto mostrato schematicamente in figura 54, e più in particolare l’area “Manager Area” della
site-view “Manager Site View”; in questa area il manager residente sul peer principale, dopo aver
selezionato una richiesta di prestito nella pagina “Start Remote Check”, avvia l’attività “Remote
Check” e invia i dati necessari al sotto-processo delegato al peer remoto. Successivamente
assegnerà a degli impiegati l’attività “Job Check”, che verrà svolta sul peer principale, e le due
attività “Remote Residence Check” e “Remote Financial Check” che rappresentano le due attività di
confine svolte sul peer remoto.
98

Progettazione delle applicazioni Capitolo 6
Figura 57 - Schermata del tool WebRatio ® relativa all’area "Manager Area"
La figura 58 mostra l’area “Employee Area” della site-view “Employee Site View” dell’applicazione
residente sul peer principale, che permette all’impiegato di poter controllare l’arrivo dei dati dal
peer remoto e procedere con le operazioni successive. Più nello specifico, attraverso la pagina
“Remote Residence Check” può selezionare la richiesta di prestito della quale sono stati ricevuti i
dati dal peer remoto dopo l’avvenuta esecuzione dell’attività “Residence Check”, e tramite l’avvio e
la terminazione dell’attività “Remote Residence Check” registrerà nella base di dati locale i metadati
relativi all’attività svolta sul peer remoto. Allo stesso modo, dalla pagina “Remote Financial
Check”, può controllare l’avvenuta ricezione dei dati dopo l’attività “Financial Check” svolta
anch’essa sul peer remoto. In questo caso, l’impiegato dovrà svolgere l’attività “Job Check”, come
previsto dal flusso di processo che stiamo trattando. Le operazioni che precedono l’assegnamento
della successiva attività “Final Validation” rispecchiano quelle descritte precedentemente.
99

Progettazione delle applicazioni Capitolo 6
Figura 58 - Schermata del tool WebRatio ® relativa all’area "Employee Area"
100

Progettazione delle applicazioni Capitolo 6
6.2. Click4aCar
Click4aCar, come già introdotto nel capitolo 2.3, rappresenta uno scenario di compravendita di
macchine usate, che è stato utilizzato per coprire l’ultimo caso di distribuzione dei processi:
- Interazione fra processi indipendenti, costituito da tre progetti separati: 4.MainCar, che
rappresenta l’applicazione relativa ad una concessionaria, 4.MainUser, l’applicazione
utilizzata dagli utenti che desiderano interagire col sistema, e 4.wsFactory, il servizio che
espone le auto disponibili all’immatricolazione.
Analizzeremo ora in dettaglio i requisiti dell’applicazione, i modelli dei dati e i passi della
progettazione dell’ipertesto.
6.2.1. Requisiti
Innanzitutto identifichiamo le due tipologie di attori che prendono parte al processo:
- User: rappresenta l’utente che può comprare o vendere la propria auto.
- Employee: rappresenta l’impiegato di un concessionario che segue le varie fasi di vita di
un’auto, dalla sua immatricolazione alla sua demolizione.
Per quanto riguarda il primo attore, possiamo individuare i seguenti requisiti funzionali: la
possibilità di effettuare una ricerca delle auto in vendita da parte del concessionario o di altri
utenti; la possibilità di acquistare un’auto; la possibilità di mettere in vendita la propria auto; e la
possibilità di visualizzare la cronologia delle auto possedute.
La figura 59 riporta un diagramma UML in cui possiamo notare le attività che permettono di
soddisfare i requisiti emersi, e in cui si può osservare che la totalità delle attività eseguibili
dall’utente richiedono il riconoscimento dello stesso mediante una fase di Login, la quale andrà a
buon fine solamente se l’utente ha in precedenza effettuato una registrazione al sistema.
101

Progettazione delle applicazioni Capitolo 6
Figura 59 - Use Case Diagram per l'attore "User"
Per la seconda tipologia di utente del sistema, l’Employee, possiamo individuare i seguenti requisiti
funzionali: la possibilità di visualizzare le auto prodotte dalle case costruttrici, di immatricolarle,
venderle, acquistarle e poterle demolire.
Le attività che permettono di soddisfare questi requisiti sono riportate nel diagramma UML in figura
60, dove possiamo notare che tutte le attività richiedono una fase di Login al sistema, e che
l’attività di immatricolazione di un’auto necessita di una fase di visualizzazione delle auto disponibili
all’immatricolazione.
Visualizzare auto
da immatricolare
Immatricolare
un'auto
Login
Employee
Acquistare un'auto
Vendere un'auto
Figura 60 - Use Case Diagram per l'attore "Employee"
102

Progettazione delle applicazioni Capitolo 6
6.2.2. Modello dei dati
Per quanto riguarda le due applicazioni principali, per gli utenti e per la concessionaria, esse
presentano il medesimo modello dei dati, in cui abbiamo individuato l’ oggetto Core “Car”, il quale
permette di gestire le informazioni riguardanti una determinata auto.
In figura 61 sono stati evidenziati i diversi sotto-schemi e la parte riguardante il meta-modello dei
dati di workflow, necessario per poter utilizzare l’estensione per i workflow di WebML.
Figura 61 - Modello dei dati per le applicazioni "4.MainCar" e "4.MainUser"
Il terzo progetto è costituito da un servizio semplice che esporta le auto disponibili
all’immatricolazione, e per questo il suo modello dei dati è composto dalla sola entità “Car”; sono
assenti i meta-dati di workflow e il sotto-schema di personalizzazione:
Figura 62 - Modello dei dati per il progetto "4.wsFactory"
103

Progettazione delle applicazioni Capitolo 6
6.2.3. Ipertesto
Come abbiamo visto per Click4aLoan, presentiamo innanzitutto l’organizzazione delle site-view e
successivamente le porzioni di ipertesto che consentono la realizzazione dello scenario di
distribuzione implementato.
6.2.3.1. Organizzazione delle site-view
L’organizzazione delle site-view varia a seconda dell’applicazione:
o 4.MainCar: composto dalle site-view: “Public Site View”, che permette all’utente che
gestisce il concessionario di effettuare la login al sistema; “Employee Site View”, che
permette di immatricolare, comprare e demolire delle auto, e di gestirne la
compravendita; “Web Service”, con layout di pagina “SOAP Envelope” e stylesheet “Web
services”, che permette di esportare i servizi per la pubblicazione delle auto disponibili, e
per le fasi di acquisto e vendita.
o
4.MainUser: composto dalle site-view: “Public Site View”, che permette all’utente di
effettuare la login al sistema o di registrarsi; “User Site View”, che permette di comprare e
vendere le auto, e di inviare i relativi dati all’applicazione del concessionario; “Web
Service”, che permette di esportare un servizio che permette di ricevere i dati dal
concessionario relativi alle auto in vendita e alle auto acquistate da parte dell’utente
corrente.
o 4.wsFactory: che rappresenta il servizio remoto che offre le auto disponibili
all’immatricolazione, ed è composto dalla site-view “New Cars”, la quale presenta i servizi
per esportare le auto e per notificarne la loro immatricolazione.
6.2.3.2. Implementazione degli scenari di distribuzione
A differenza del caso di studio precedente, in Click4aCar, non è presente un unico flusso di
processo suddiviso su diversi peer, ma presenta due workflow distinti che interagiscono tra loro
secondo modalità non definite a priori. Infatti per tutti gli scenari analizzati per Click4aLoan,
vengono delegate ai peer remoti delle attività componenti il flusso di processo, o addirittura sottoprocessi,
mantenendo però inalterata la struttura del workflow; questo significa che il flusso di
processo aveva un avanzamento definito e non mutevole. In Click4aCar, i due flussi di processo,
invece, seguono comportamenti indipendenti l’uno dall’altro, ed entrano in comunicazione quando è
104

Progettazione delle applicazioni Capitolo 6
necessario scambiarsi dati essenziali per il proseguimento del loro corso. L’ordine delle operazioni
non è predeterminato, ma varia a seconda del comportamento tenuto dagli utenti.
Riporteremo ora dei frammenti di ipertesto che ci permettono di far comprendere come è stata
realizzata l’interazione fra i due flussi di processo indipendenti; più precisamente descriveremo le
interazioni evidenziate nel diagramma in notazione BPMN riportato in figura 63:
User 1
Car
User 2
Manufacture
Matriculation
Will Sell
For Sale
Will Sell
Search Car
Purchase / Sale
Search Car
x
Usage
Demolition
Usage
Figura 63 - Interazione da analizzare
La figura mostra un esempio di interazione fra i due flussi di processo, e più precisamente fra una
istanza del workflow del concessionario e due istanze del workflow degli utenti. L’esempio riporta il
caso in cui un primo utente desidera mettere in vendita la propria auto e un secondo che voglia
acquistarla, attraverso l’utilizzo di un intermediario, in questo caso il concessionario.
Il primo utente, quindi, invia i dati dell’auto da vendere al concessionario, il quale li pubblicherà
insieme a tutti quelli riguardanti le altre auto in vendita attraverso la pubblicazione di un servizio
Web. Il secondo utente, che intende acquistare un’auto, invoca il Web Service in questione e
sceglierà l’auto del primo utente fra quelle proposte, inviando la sua richiesta al concessionario. A
105

Progettazione delle applicazioni Capitolo 6
questo punto il concessionario provvederà a convalidare la transazione inviando una conferma di
vendita e di acquisto rispettivamente al primo e al secondo utente. Infine, quest’ultimo potrà
utilizzare l’auto appena acquistata, proseguendo nel suo flusso di processo.
Riportiamo ora i frammenti di ipertesto che modellano le interazioni fra le applicazioni, a cominciare
dai servizi web pubblicati nel progetto 4.wsFactory, che offrono all’applicazione del concessionario
la lista delle auto pronte all’immatricolazione, rappresentando così una sorta di casa costruttrice
automobilistica. L’applicazione del concessionario invocherà il Web Service “Available Cars” per
recuperare la lista delle auto disponibili, ed utilizzerà il secondo Web Service “Matriculated Car” per
informare il costruttore dell’avvenuta immatricolazione e permettere l’eliminazione dell’auto dalla
sua base di dati; i due Web Service sono rappresentati in figura 64:
Figura 64 - Frammento di ipertesto della site-view "New Cars" del progetto wsFactory
In figura 65, invece, sono riportati i servizi pubblicati dall’applicazione del concessionario
(4.MainCar), attraverso i quali l’utente può: recuperare la lista delle auto attualmente in vendita da
parte del concessionario stesso o da parte di altri utenti invocando “SaleableCar”, informare il
concessionario dell’acquisto di un’auto fra quelle disponibili invocando “BoughtCar”, e informarlo
dell’intenzione di vendere un’auto invocando “SellCar”.
Figura 65 - Frammento di ipertesto della site-view "Web Service" dell’applicazione del concessionario
106

Progettazione delle applicazioni Capitolo 6
L’applicazione dell’utente, d’altro canto, pubblica anch’essa dei Web Service per poter ricevere dal
concessionario delle notifiche a fronte dell’avvenuta vendita dell’auto o a fronte della conferma di
acquisto, rispettivamente attraverso i servizi “CarSold” e “CarPurchased” rispettivamente.
Figura 66 - Frammento di ipertesto della site-view "Web Service" dell’applicazione dell’utente
Per quanto riguarda gli ipertesti che utilizzano questi Web Services, riportiamo un frammento
dell’ipertesto della site-view “Employee Site View” dell’applicazione del concessionario:
Employee Site View (MainCar)
Matriculation Page
Params
Available Cars
Available Cars
Search for New
Cars
OK
Adapter Unit
OK
XML In Unit
OK
Available Cars
Selected Car
D
Params
Params
Car
Car
End Unit
Params
OK
Assign Unit
Params
OK
Assign Unit
Send Data to
wsFactory
Params
OK
Create Car
Params
OK
Start Unit
Matriculation
Demolition
Buy
Car
Matriculation
[Start Case]
Transactions Page
Pending
Transactions
Selected Car
Send Data to
Buyer
Send Data to
Seller
Modify Unit
Car
[Will Sell = 0]
[Owned = 0]
Car
L
OK
Car
Figura 67 - Frammento di ipertesto della site-view "Employee Site View" dell’applicazione del concessionario
Dalla pagina “Matriculation Page”, l’impiegato del concessionario, cliccando sul link “Available
Cars”, avvia l’invocazione del Web Service “Available Cars”, il cui risultato sarà memorizzato in un
database virtuale, dal quale è possibile selezionare l’auto da immatricolare e di conseguenza
107

Progettazione delle applicazioni Capitolo 6
avviare l’attività “Matriculation”, che comporta l’avvio del “Case” relativo a quella determinata
auto; ad essa segue una Create Unit, che permette di inserire la nuova auto nella base di dati
reale. Il passo successivo è quello di avvisare il costruttore dell’avvenuta immatricolazione dell’auto
scelta, attraverso l’invocazione del Web Service “Matriculated Car”; a questo punto vengono
assegnate all’utente corrente le successive attività di acquisto e di demolizione riferite all’auto
scelta. Questo assegnamento è necessario, in quanto queste due attività dovranno, in futuro,
essere eseguite obbligatoriamente dal concessionario per poter terminare il flusso di processo.
L’ultimo passo prevede la terminazione dell’attività “Matriculation” attraverso una End Unit.
Dalla pagina “Transactions Page”, l’impiegato può visionare le transazioni di acquisto-vendita in
corso, dalle quali può selezionare quella desiderata e dare la propria approvazione. A questo punto
verranno invocati i due Web Service degli utenti, per avvisare l’acquirente dell’avvenuto acquisto
dell’auto e il venditore dell’avvenuta vendita; successivamente verranno apportate le modifiche
necessarie alla base di dati.
La fase di approvazione di una transazione di acquisto-vendita da parte del concessionario è stata
introdotta in quanto, sempre per i motivi descritti per gli altri progetti, non è attualmente possibile
eseguire un’invocazione di un servizio Web in una site-view che presenta layout di pagina e
stylesheet adatti alla pubblicazione di servizi Web, come la site-view “Web Service”.
Riportiamo ora degli snapshot del tool WebRatio ®
della site-view in esame riferiti agli esempi
appena descritti.
La figura 68 mostra l’area “Matriculation” che contiene le pagine “Matriculation Page” e “Available
Cars” descritte precedentemente; tale area è contrassegnata come “landmark” per poter essere
raggiunta da ogni punto della navigazione all’interno della site-view dell’impiegato, e la sua pagina
di default è “Matriculation Page”. La pagina “Available Cars” è raggiungibile solamente dopo
l’invocazione del Web Service che fornisce la lista delle auto disponibili. Le operazioni successive
sono invisibili all’utente, al quale sarà mostrata solamente una pagina, “Matriculation OK”, di
conferma dell’avvenuta immatricolazione, nel caso queste andassero a buon fine, e una pagina di
errore nel caso contrario.
In figura 69 è riportata la pagina che mostra le auto disponibili all’immatricolazione che si presenta
all’impiegato, e dalla quale è possibile selezionare l’auto desiderata e procedere alla sua
immatricolazione attraverso il link “Matriculate”.
108

Progettazione delle applicazioni Capitolo 6
Figura 68 - Schermata del tool WebRatio ® relativa all'area "Matriculation"
Figura 69 - Pagina "Available Cars" dell’applicazione 4.MainCar
La figura 70 mostra l’area landmark “Approve Tansactions”, in cui è presente la pagina di default
“Transaction Page”, che è stata descritta precedentemente, e dalla quale l’impiegato può
109

Progettazione delle applicazioni Capitolo 6
selezionare una delle transazioni da approvare. Le operazioni che seguono sono quelle descritte in
figura 67, e sono invisibili all’utente, il quale è portato alla pagina “Transaction Approved” se esse
sono andate a buon fine, o ad una pagina di errore in caso contrario.
Si possono notare le due invocazioni dei Web Services dell’applicazione relativa agli utenti, per
notificare l’avvenuta approvazione all’acquirente e al venditore.
Figura 70 - Schermata del tool WebRatio ® relativa all'area "Approve Transactions"
Figura 71 - Pagina "Approve Transactions" dell’applicazione 4.MainCar
110

Progettazione delle applicazioni Capitolo 6
In figura 71 è riportata la pagina che viene mostrata all’impiegato, la quale mostra le transazioni in
attesa di approvazione, dalla quale è possibile selezionare quella desiderata e procedere alla sua
approvazione attraverso il link “Approve”.
Per quanto riguarda l’applicazione relativa agli utenti, riportiamo due frammenti dell’ipertesto della
site-view “User Site View”; il primo, riportato in figura 72, mostra la sequenza delle operazioni
svolte quando un utente desidera mettere in vendita la propria auto. Dalla pagina “Sell your Car”,
l’utente può scegliere l’auto da mettere in vendita, terminando così l’attività “Usage”; la pagina
successiva permette di inserire il prezzo di vendita dell’auto e porterà ad avviare l’attività di
vendita “Sell”, durante la quale verranno inviati i dati dell’auto all’applicazione del concessionario,
mediante l’invocazione del Web Service “Sell Car”, e apportate le modifiche opportune sulla base di
dati locale.
Figura 72 - Frammento di ipertesto della site-view "User Site View" dell’applicazione relativa agli utenti
L’utente sarà portato in una pagina di refresh per controllare se l’auto è stata venduta e la
transazione approvata dal concessionario; in caso affermativo, sarà terminata l’attività di vendita,
comportando così la terminazione del “Case” relativo a quella determinata auto.
La figura 73 mostra il secondo frammento di ipertesto, nel quale possiamo notare le fasi
dell’acquisto di un’auto da parte di un utente. Attraverso la pagina “Buy a Car” e il link “Check for
Available Cars”, verrà invocato il servizio Web “Saleable Car” pubblicato dall’applicazione del
concessionario, attraverso il quale è possibile recuperare le informazioni relative alle auto in
vendita. Queste informazioni sono memorizzate in un database virtuale, e solo dopo che l’utente
avrà scelto l’auto desiderata e dopo che sarà stata avviata l’attività “Purchase”, saranno
111

Progettazione delle applicazioni Capitolo 6
memorizzate nel database reale, ma solo per quanto riguarda l’auto selezionata; l’attività
“Purchase” segna anche l’inizio del “Case” relativo a tale auto. I dati così memorizzati saranno
connessi all’utente corrente attraverso una “Connect Unit”, ed inviati all’applicazione del
concessionario attraverso l’invocazione del Web Service “Bought Car”, per informarlo della scelta
dell’utente; il concessionario provvederà in seguito ad approvare la transazione acquisto-vendita.
La pagina “Check Concessionarie Approvals” consente quindi all’utente di verificare l’effettiva
approvazione della transazione acquisto-vendita da parte del concessionario, e di proseguire con la
terminazione dell’attività di acquisto. La pagina successiva permette all’utente di iniziare l’attività di
“Usage” dell’auto e di assegnare la futura attività di vendita.
User Site View (MainUser)
Buy a Car
Params
Available Cars
Check for Available Cars
Search for
Available Cars
OK
Adapter Unit
OK
XML In Unit
OK
Available Cars
Selected Car
L
Params
Params
Car
Car
Assign Unit
Buy Car
Params
Connect Unit
Params
Create Car
Params
Start Unit
OK
OK
OK
OK
Usage
User_2_Car
Car
Purchase
[Start Case]
Params
Check Concessionaire Approvals
Transaction Approved
Car Summary
End Unit
Car Summary
Start Unit
Params
Assign Unit
OK
OK
Car
[Owned = 1]
L
Purchase
Car
[Owned = 1]
Usage
Sell
Figura 73 - Frammento di ipertesto della site-view "User Site View" dell’applicazione relativa agli utenti
L’implementazione di questo frammento di ipertesto nel tool WebRatio ® è stata riportata in figura
74, in cui viene mostrata l’area “Buy Car”, contenente le pagine descritte in precedenza, e la
pagina “Car Bought”, nella quale viene portato l’utente se tutte le operazioni sono andate a buon
fine.
Un’ultima precisazione su questo ipertesto riguarda il fatto che le informazioni relative all’auto che
l’utente ha intenzione di acquistare vengono inserite nella base di dati al momento della scelta
dell’auto, e che vengono successivamente modificate al momento dell’approvazione della
112

Progettazione delle applicazioni Capitolo 6
transazione acquisto-vendita da parte del concessionario, per rendere così disponibile all’uso l’auto
acquistata, attraverso la modifica del campo “Owned”.
Figura 74 - Schermata del tool WebRatio ® relativa all'area "Buy Car"
113

Related Work Capitolo 7
7. Related Work
114

Related Work Capitolo 7
I sistemi che gestiscono flussi di processo sono ampiamente utilizzati dalle organizzazioni per
automatizzare i loro processi di business. Tuttavia i sistemi di workflow attualmente disponibili
tendono ad assumere una struttura monolitica e non orientata al Web. Per questo motivo la ricerca
si sta focalizzando sulla realizzazione di architetture decentralizzate per la gestione dei workflow.
D’altro canto molti ricercatori hanno colto le potenzialità degli ipertesti come formalismo per la
rappresentazione di computazione in generale, e di processi organizzativi in particolare.
Il nostro lavoro non cerca di realizzare un’architettura per gestire la distribuzione dei flussi di
processo, ma di sfruttare l’integrazione fra il design degli ipertesti e i processi di business per poter
realizzare applicazioni web che permettano di distribuire i flussi di processo su diversi server,
evitando la realizzazione di un motore ad hoc per la loro gestione, come avviene per diversi tool
presenti sul mercato.
Molte piattaforme e linguaggi esistenti consentono l’integrazione fra il design delle applicazioni web
e i processi di business; alcuni di essi verranno ora descritti, indicandone analogie e differenze con
il nostro lavoro.
PML (Process Modeling Language) [12] è una semplice formalizzazione per la descrizione di
processi, che consente di descrivere semplici concetti di workflow. La specifica PML può essere
inoltre compilata in una semplice piattaforma Web. L’ipertesto orientato ai processi generato è
concettualmente simile a quello proposto da WebML, la differenza sostanziale consiste nell’utilizzo
di modelli di alto livello: noi basiamo il nostro approccio sul modello di applicazione Web di WebML,
dotata di una notazione grafica; mentre PML è semplicemente un modello di processo semplificato,
rappresentato da un’essenziale sintassi. Una seconda differenza consiste nel meccanismo usato per
controllare lo stato del processo. Il nostro lavoro si basa sul controllo dei workflow attraverso la
presenza di un insieme speciale di entità, che creano i meta-dati di workflow, in armonia con la
filosofia di WebML, che basa il modello di ipertesto su un modello dei dati. Al contrario PML non si
focalizza sulla modellazione dei dati coinvolti nel processo, e delega il controllo del workflow ad un
processo ad hoc detto "lightweight process runtime". Infine PML non permette la personalizzazione
dell’interfaccia Web di una data attività, in quanto per ogni attività viene generata solamente una
pagina, a dispetto della sua complessità. Al contrario il nostro lavoro è basato su WebML, che ha un
importante potere espressivo sia per i modelli di ipertesto di alto livello che per quelli dettagliati.
OO-H [13] è un approccio parzialmente object-oriented per modellare applicazioni Web integrate
con i processi di business. I passi della metodologia, chiaramente separati, sono definiti per il
115

Related Work Capitolo 7
design dei modelli concettuali di navigazione, di presentazione e di processo. Per la modellazione
dei processi, viene offerto un insieme di regole che trasformano la definizione del processo di base
in un modello di navigazione per l’utente. Per questo motivo, la struttura di navigazione è
determinata da un modello di workflow. La navigazione con i link dell’utente corrisponde ad un
flusso di processo.
Analogamente in UWE [14], il design del processo è definito da modelli separati. Come in OO-H, il
modello di navigazione è esteso con primitive di processo che trasferiscono l’utente dentro e fuori i
confini del flusso di processo. In entrambi i metodi, il data model è implementato con l’utilizzo dei
diagrammi delle classi forniti da UML ed è integrato con gli elementi del processo. Non vi sono i
meta-dati di processo: i tasks sono direttamente modellati come metodi di classe e le attività del
processo sono eseguite invocando questi metodi. Di conseguenza la gestione e il monitoraggio del
processo è abbastanza complessa. Nel nostro lavoro il modello dei dati è basato sullo schema
Entità-Relazione ed è esteso con i meta-dati di workflow, in modo tale da offrire esplicitamente
informazioni circa la struttura e il flusso di processo.
In OOHDM [15], i modelli di contenuto e di navigazione sono estesi con activity entities e activity
nodes rispettivamente, rappresentate da primitive UML. Inoltre, l’esecuzione del processo avviene
all’interno di un contesto navigazionale che specifica le regole di accesso per i processi
corrispondenti.
In WSDM [16], la progettazione del processo è guidata dai requisiti dell’utente ed è basata sulla
notazione ConcurTaskTrees. Il modello di processo è specificato nel design concettuale. In
particolare, durante la prima fase che è il Task Modelling, viene definita una gerarchia delle
operazioni, vengono espresse le condizioni temporali fra i task da operatori e le informazioni e/o
funzionalità definite da ciascun task vengono modellate da porzioni di oggetti. Durante la seconda
fase della progettazione concettuale, il Navigational Design, la struttura della navigazione utente è
generata per mezzo di componenti e link per realizzare i task modellati. L’approccio proposto è
simile al nostro, per il fatto che la struttura viene generata al di fuori della descrizione concettuale
dei processi, ma gli autori usano una notazione per la descrizione del processo non standard.
Anche Araneus [17] permette la generazione di applicazioni web partendo dal design dell’ipertesto
ad alto livello, ed è stato esteso con un modello concettuale per la progettazione di workflow, ma
differentemente da quanto ci prefiggiamo noi, quest’ultimo integra un Workflow Management
System per la gestione dei flussi di processo, non consentendo la loro distribuzione; il nostro lavoro
invece si basa sull’integrazione dei workflow all’interno della progettazione dell’ipertesto per
116

Related Work Capitolo 7
permetterci di distribuirne il flusso di processo, senza la necessità di realizzare un Workflow
Management System ad hoc, ma utilizzando tecnologie già esistenti e affermate (Web Service).
Un approccio parallelo al nostro è quello introdotto da BPEL4WS e da altri linguaggi di
orchestrazione di Web Service, che, come visto nel capitolo 3, forniscono linguaggi per la specifica
formale di processi di business e protocolli di interazione, per mezzo dell’estensione del modello di
interazione dei Web Service, permettendo di supportare le transazioni di business. Ad esempio, il
linguaggio fornito da BPEL4WS permette di definire un nuovo Web Service attraverso la
composizione di un insieme di Web Service esistenti seguendo il flusso di operazioni dettato da un
workflow. Il nostro scopo, come già accennato in precedenza, è invece quello di utilizzare la
tecnologia dei Web Service come strumento per implementare flussi di processo, permettendo di
distribuirne la loro computazione.
117

Conclusioni Capitolo 8
8. Conclusioni
118

Conclusioni Capitolo 8
Al termine del nostro lavoro di tesi, volto allo studio dei diversi scenari di distribuzione applicabili a
processi aziendali, abbiamo potuto riscontrare come tutti gli obiettivi da noi prefissati siano stati
raggiunti. Lo sviluppo di questo lavoro ci ha consentito di acquisire nozioni teoriche e notazioni
circa il mondo dei workflow, conoscenze sugli standard, il meta-linguaggio XML e le trasformazioni
XSL proprie del mondo dei Web Service, e capacità di modellazione ad alto livello di applicazioni
Web data-intensive.
La fase iniziale del nostro lavoro, ci ha permesso di esprimere ogni schema e ogni politica di
distribuzione in maniera concettuale, attraverso uno studio teorico dei diversi scenari riscontrabili
nell’ambito dei workflow distribuiti, punto di partenza per una successiva modellazione delle
relative applicazioni, non legato ad una particolare piattaforma implementativa.
La seconda fase si è concentrata sull’implementazione degli scenari individuati, e la realizzazione
dei relativi prototipi mediante il linguaggio di modellazione WebML, le sue estensioni per la gestione
dei workflow e dei Web Service, e il CASE tool WebRatio ® , che ci ha portato a comprendere come
gli ipertesti che implementano processi distribuiti vengono progettati con la stessa metodologia di
quelli centralizzati, tenendo conto di particolari accorgimenti:
Individuare lo scenario di distribuzione adatto alla tipologia di applicazione da
implementare.
Organizzare l’applicazione in diversi progetti da suddividere sui vari peer.
Progettare le basi di dati tenendo conto della presenza o meno dei meta-dati di workflow
sui vari peer.
Scegliere il modello appropriato per lo scambio dei messaggi: Push/Pull; e pubblicare i Web
Service necessari.
WebML, e le relative estensioni per i Workflow e i Web Service, si presta bene alla modellazione
della distribuzione dei processi, anche se, oltre a certi pregi, presenta anche dei difetti.
La limitazione più pesante che abbiamo riscontrato durante l’implementazione dei diversi scenari di
distribuzione, è dovuta al CASE tool WebRatio ® , e più in particolare riguarda le caratteristiche delle
site-view atte alla pubblicazione di Web Service, in cui viene impostato il layout di pagina sul valore
“SOAP Envelope” e lo stylesheet su “Web services”; infatti, queste site-view presentano dei
problemi per quanto riguarda il corretto funzionamento di determinate unit necessarie, ad esempio,
ad implementare uno scenario automatico per il controllo del flusso di processo, come le unit Start,
End, Assign Activity, dell’estensione per i Workflow di WebML.
119

Conclusioni Capitolo 8
Queste unit richiedono, ad esempio, determinati parametri in ingresso non disponibili in queste
determinate site-view, oppure richiedono di essere attivate da un link cliccabile dall’utente, cosa
non possibile in site-view di questo tipo, dato che non vengono generate pagine jsp, ma documenti
XML.
È facile intuire come queste limitazioni influenzano l’ipertesto risultante, che può differire di molto
da quello previsto; questa però è una conseguenza minima in confronto al fatto che viene stravolto
anche il percorso navigazionale dell’utente che andrà ad utilizzare l’applicazione, il quale dovrà
partecipare attivamente a determinate fasi del processo che erano state pensate come
automatiche.
In questo ambito, si intravede un possibile sviluppo futuro della piattaforma, consistente nel fatto
di estendere il linguaggio per poter gestire la notifica all’utente di modifiche alla base di dati, che
permetterebbe un migliore approccio al problema, che in questo lavoro si è cercato di risolvere
attraverso pagine di “refresh” per controllare lo stato di determinati attributi nella base di dati.
Inoltre, per poter gestire al meglio la distribuzione dei processi, si intravede la possibilità di
aggiungere ai meta-dati di workflow introdotti dalla relativa estensione del linguaggio WebML,
un’ulteriore entità per poter assegnare un’istanza di attività non solo ad un utente o ad un gruppo
di utenti, ma anche ad un determinato peer della rete in cui si sviluppa lo scenario distribuito.
Questa entità “Peer” andrebbe a relazionarsi con l’entità già esistente “Activity Instance”, la quale
contiene le istanze di attività. Questa variante però introdurrebbe delle modifiche alla unit Assign,
nonché l’introduzione di ulteriori meccanismi per il rilevamento dei peer connessi alla rete e per la
gestione delle nuove tipologie di eccezioni che scaturirebbero.
A proposito di eccezioni, gli scenari da noi implementati in questo lavoro di tesi, risentono in
maniera rilevante di un problema risolvibile attraverso una nuova gestione delle eccezioni, e più
precisamente la possibilità dell’utente di utilizzare il pulsante “Back” del browser durante la
navigazione nell’applicazione Web, e in maniera più rilevante quando questo viene fatto in punti
della navigazione che riguardano l’interazione fra diversi peer. Senza una nuova gestione delle
eccezioni, sarebbe possibile, ad esempio, inviare più volte dei dati ad un determinato peer.
Se da un lato sono stati individuati dei difetti, WebML e le sue estensioni hanno anche molti pregi.
Nonostante il fatto che le unit messe a disposizione dal linguaggio e dalla sua estensione per i
workflow siano state ideate per modellare flussi di processo residenti su di un unico peer, esse si
prestano bene anche alla modellazione di scenari distribuiti. Inoltre permettono una facile e veloce
120

Conclusioni Capitolo 8
pubblicazione-invocazione dei Web Service necessari allo scambio dei messaggi fra i vari peer
coinvolti nel processo, dovuta anche a degli accorgimenti del tool WebRatio ® , come ad esempio, il
wizard per la creazione di trasformazioni XSL integrato in esso.
Il nostro lavoro, con lo studio dei diversi scenari di distribuzione individuabili nel mondo dei
workflow, ha posto le basi per un futura espansione di un tool già esistente, che permette di
effettuare una verifica formale e opera trasformazioni semi-automatiche di diagrammi BPMN per la
generazione di modelli di ipertesto basati sullo standard WebML, per consentire il supporto alla
distribuzione dei flussi di processo.
Il lavoro di progettazione svolto con WebRatio ® consente di affermare che la piattaforma attuale è
in grado di offrire un ambiente capace di supportare la modellazione di ogni scenario di
distribuzione relativo a processi aziendali mediante un’architettura basata su Web Services, a
fronte della risoluzione delle problematiche individuate.
121

Bibliografia
[1] Introduction to Workflow. Charles Plesums, Computer Sciences Corporation, Financial
Services Group.
[2] Towards Distributed Workflow Process Management. Johann Eder, Euthimios Panagos
AT&T Labs – Research.
[3] The Workflow Reference Model. http://www.wfmc.org/standards/docs/tc003v11.pdf
[4] Introduction to BPMN. Stephen A.White IBM Corporation.
[5] Designing Data-Intensive Web Applications. S. Ceri, P. Fraternali, A. Bongio, M. Brambilla,
S. Comai, M. Matera. Morgan-Kaufmann, 2002.
[6] Design and Maintenance of Data-Intensive Web Sites. Atzeni, Mecca, Merialdo.
[7] Web Modeling Language (WebML): a modeling language for designing Web sites. S.
Ceri, P. Fraternali, A. Bongio, 2000.
[8] Building Web Applications with UML. J. Conallen. Addison-Wesley, 2002.
[9] Web services orchestration. A review of emerging technologies, tools, and standards,
Chris Peltz, HP Co., 2003.
http://devresource.hp.com/drc/technical_white_papers/WSOrch/WSOrchestration.pdf
[10] WebRatio extensions for Workflows – User Manual. WebSI Project IST-2001-35458.
Politecnico Di Milano.
[11] WebRatio extensions for Web Services - User Manual. WebSI Project IST-2001-35458.
Politecnico Di Milano.
[12] Specifying process-oriented hypertext for organizational computing. Journal of
Network and Computer Applications, Vol. 24, J. Noll, W. Scacchi, 2001.
[13] Advanced Conceptual Modeling of Web Applications: Embedding Operation Interfaces
in Navigation Design. C. Cachero, J. Gòmez, 2002.
122

[14] The Expressive Power of UML-based Engineering. N. Koch, A. Kraus, 2002.
[15] Engineering Business Processes in Web Applications: Modeling and Navigation Issues.
L. Rossi, H. Schmid, F. Lyardet, 2003.
[16] Modeling Complex Processes for Web Applications using WSDM. O. Troyer, S. Casteleyn,
2003.
[17] Design and development of data-intensive Websites: the Araneus approach. P.
Merialdo, P. Atzeni, G. Mecca, 2003.
[18] “Extending hypertext conceptual models with process-oriented primitives”. M.
Brambilla. Politecnico di Milano.
[19] “Model-driven Specification of Web Services Composition and Integration with Dataintensive
Web Applications”. M. Brambilla, S. Ceri, S. Comai, P. Fraternali, I. Manolescu.
Politecnico di Milano.
[20] “Model-driven development of Web Services and hypertext applications”. M. Brambilla,
S. Ceri, S. Comai, P. Fraternali. Politecnico di Milano.
[21] “Process Modeling in Web Applications” M. Brambilla, S. Ceri, P. Fraternali. I. Manolescu.
Politecnico di Milano.
[22] “Methodology For the Design of WebSI Applications”. WebSI Politecnico di Milano.
[23] “XSL Transformations (XSLT) Version 1.0” W3C.
http://www.w3.org/TR/1999/REC-xslt-19991116
[24] WebML Project Website. http://www.webml.org
[25] WebRatio ® Website. http://www.webratio.com
[26] UML Website: http://www.uml.org
[27] Workflow Management Coalition Website. http://www.wfmc.org
123