Capitolo 2 Progettazione del terminale SIFA

Capitolo 2
Progettazione del terminale SIFA
Il terminale SIFA è un sistema polifunzionale e molto complesso. Per tale motivo la
consegna del progetto prevedeva l’implementazione di un processo BPEL contenente solo
alcune procedure che il terminale SIFA reale implementa.
Tra queste abbiamo scelto le procedure di iscrizione all’esame e di cancellazione dell’iscrizione
ad un esame. Nel dettaglio il workflow di funzionamento del nostro terminale SIFA
è il seguente:
Un utente si collega fornendo la matricola, a questo punto può scegliere se iscriversi ad
un esame o cancellarsi da un esame a cui risultava precedentemente iscritto. In caso di
scelta della prima operazione, l’iscrizione, all’utente viene mostrata la lista degli esami
disponibili. L’utente a questo punto sceglie a quale esame iscriversi e conferma la scelta.
Il sistema effettuerà l’iscrizione all’esame ed invierà una mail di conferma all’indirizzo
email dell’utente stesso.
Se alla prima scelta l’utente decidesse invece di cancellarsi da un esame a cui risultava
precedentemente iscritto, il workflow sarebbe leggermente diverso. La scelta verrebbe
eseguita sulla lista esami a cui l’utente risulta già iscritto, mentre alla conferma il sistema
procederebbe nella cancellazione avvisando sempre l’utente con una mail.
Definito questo workflow, che non è altro che la rappresentazione discorsiva del futuro
BPEL, è stato necessario capire come progettare i servizi che il processo BPEL andrà poi
a chiamare. Abbiamo optato per creare due web services, uno dedicato alle operazioni
di iscrizione, cancellazione e di ricezione delle liste esami, l’altro dedicato all’invio mail.
Questa tipologia di architettura ci è sembrata molto conveniente e segue un’approccio
DRY nell’affrontare il problema, poichè adibire all’invio mail un web service dedicato permette
essere meno ripetitivi nella definizione del web service gestore esami. Ciò significa
che il web service mailer si occupa solo di spedire le mail:
• Invia mail: riceve in input il tipo di messaggio, il codice esame e la matricola
Il web service gestore esami invece è stato definito con le seguenti operazioni:
• Iscrizione: riceve in input il codice esame e la matricola
• Cancellazione: riceve in input il codice esame e la matricola
3

4 Capitolo 2. Progettazione del terminale SIFA
• Ricezione della lista esami disponibili: riceve in input la matricola
• Ricezione della lista esami a cui l’utente è iscritto: riceve in input la matricola
Ovviamente questi web service effettuano alcune operazioni in modo intrinseco, ad esempio
il web service mailer cerca automaticamente l’indirizzo email associato ad una tale
matricola.
Progettare il flusso BPEL una volta definiti i web services e definita la sequenza delle
operazioni è risultato decisamente banale. Vedremo in pratica nel capitolo seguente come
è stato implementato il progetto secondo i costrutti BPEL, associando le chiamate ai web
service in modo coerente con ciò che è stato descritto nella fase di progettazione.