Modellazione concettuale di processi aziendali distribuiti basati su architettura
Web Services. Relatore: Prof. Ceri Stefano. Correlatore: Ing. Brambilla Marco.
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:
Prof. Ceri Stefano
Correlatore:
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
Usato per mostrare l’ordine in cui le attività devono essere
Flow
eseguite in un processo, e viene rappresentato da una freccia semplice.
Message
Usato
Flow
partecipanti del processo, e viene rappresentato da una
per
mostrare
il
flusso
di
messaggi
fra
due
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
Sono meccanismi per mostrare come un dato è richiesto o
Object
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.
Car
Il workflow delle auto è quello riportato in figura 3:
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
User
demolizione.
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
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.
Multidata
Permette di presentare un insieme di oggetti di un’entità, ripetendo
Unit
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. Index Unit
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
Fornisce i comandi per navigare una sequenza di oggetti, per
Unit
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. Entry Unit
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
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.
Delete Unit
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.
Modify Unit
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.
Connect Unit
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.
Disconnect
Permette di cancellare le istanze di una relazione e si applica a uno
Unit
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
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.
Logout Unit
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.
SendMail Unit
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
Permette di definire operazioni generiche la cui specifica è data
Unit
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
Permette
di
valutare
diverse
espressioni
(booleane,
Parsing Unit
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
Switch Unit
Capitolo 4
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
Questa unit viene utilizzata per estrarre dati relativi ad
Aware Index
un’istanza di una attività. Essa estrae solo le istanze relative
Unit
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.
Assign Unit
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
Viene utilizzata per ottenere lo stato di una attività.
Status Unit
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
Soap-path: che definisce l’end-point-url del Web Service.
o
Tag-name: che definisce il nome del Web Service.
o
Id: l’id della unit Solicit-Response.
o
Operation-type: che definisce il tipo di Web Service, Solicit-Response o Notification.
o
Url-path: l’id della unit o della pagina che seguono direttamente la unit SolicitResponse.
-
Per ogni parametro definito per la unit Solicit-Response sono registrate le seguenti informazioni:
o
Url-name: la destinazione del parametro.
o
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
Figura 10 - Esempio di pubblicazione di Web Service
Ed il relativo file di configurazione SOAP:
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
Tipo XML Schema
String
s:string
Text
s:string
Integer
s:int
Number
s:double
Float
s:float
Date
s:date
Boolean
s:Boolean
URL
s:string
BLOB
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
Il nome dell’operazione è il nome della Solicit-Response unit.
o
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
