Progetto e orchestrazione di web services con Uml

2 INDICE
favorire l’uso reale di tale strumento nella progettazione di tali servizi.
Descrizione dei capitoli
Nel capitolo 1 viene introdotto il concetto di Web Service, dopo una breve
digressione sulle varie tecnologie di comunicazione presenti e passate. L’ar-
chitettura dei Web Service viene quindi descritta a grandi linee relazionando
differenti scelte progettuali seguite dalle aziende produttrici di questa tec-
nologia. Vengono quindi introdotti vari aspetti associati a questa tecnologia
tra cui l’orchestrazione di Web Service.
Nel capitolo 2 viene esaminata da vicino l’orchestrazione di Web Service,
gli aspetti relativi alla sicurezza e alla comunicazione interaziendale e le
soluzioni proposte da Microsoft e IBM in merito (XLANG e WSFL). Viene
inoltre introdotto il concetto di middleware e le motivazioni del suo succes-
so.
Nel capitolo 3 vengono invece ripresi dettagliatamente i due linguaggi di
specifica introdotti nel capitolo 2 (XLANG e WSFL) e vengono empirica-
mente comparati verificando la capacita` di descrivere l’uno tramite l’altro
e considerandone le proprieta` di entrambi. Vengono quindi effettuate con-
siderazioni sulle loro caratteristiche comparate e sul loro modo differente di
porre l’accento sull’orchestrazione di Web Service.
Nel capitolo 4 viene brevemente introdotto il linguaggio di modellazione
UML. Vengono quindi determinate le linee guida nella progettazione e or-
chestrazione con WSFL di Web Service attraverso UML e le motivazioni di
tale idea.
Nel capitolo 5 vengono riassunti i risultati del lavoro.
Capitolo 1
Introduzione ai Web Service
1.1 Diffusione delle tecnologie di comunica-
zione
La tecnologia Client-Server ha risposto, negli anni passati, all’esigenza di
interrogare dispositivi remoti, sfruttandone le risorse e le capacita` elabora-
tive. La possibilita` di ottenere un servizio1 era relegata alla capacita`, da
parte di dispositivi fruitori, i client, di poter interrogare dispositivi serven-
ti, i server, opportunamente scelti, sottoponendo loro richieste e ottenendo
appropriate risposte (si veda fig. 1.1).
I protocolli con cui tali dispositivi comunicavano tra loro erano disparati
e tra loro non compatibili. L’evoluzione della comunicazione ha seguito
strade differenti evolvendosi in svariate nuove forme in funzione di diffe-
renti motivazioni. Una direzione in particolare ha favorito lo sviluppo di
comunicazioni tra client e server attraverso Internet, sfruttando gli standard
che questa aveva gia` fatto prosperare e favorendo quindi lo sviluppo di co-
municazioni client-server attraverso protocolli altamente diffusi. Si e` quindi
sviluppato il concetto di applicazioni web-based, in cui un client accede al
server attraverso un protocollo basato sul web2. E` doveroso sottolineare
che anche altre strade sono state percorse, come ad esempio lo sviluppo
1
Il senso di servizio e` qui da intendersi come insieme costituito da una o piu` richieste
di funzionalita`
2ovvero tcp/ip, http e html
3
4 1. INTRODUZIONE AI WEB SERVICE
Figura 1.1: Comunicazione client-server
di comunicazioni peer-to-peer (notoriamente abbreviato in p2p) in cui la
comunicazione tra client e server diventa bivalente ed ognuna delle parti
svolge entrambi i ruoli ma il problema di utilizzare protocolli poco diffusi
ha costituito uno dei principali motivi di scarsa interoperabilita` di queste
ed altre soluzioni.
Una certa convergenza tra p2p e Web Service, tecnologia di cui parlere-
mo successivamente, si e` diffusa negli ultimi tempi ed e` stata brevemente
descritta nel par. 1.2.6. La comunicazione a livello aziendale si e` evolu-
ta invece in maniera differente. La principale esigenza che ha sospinto gli
interessi delle aziende e` stata la ricerca di una soluzione alla possibilita`
di connettere tra loro direttamente tutte le componenti interne ai sistemi
aziendali. Si e` delineata l’esigenza di connettere tra loro differenti elementi
quali acquirenti, venditori, fornitori attravero una tecnologia che sfruttasse
le infrastrutture esistenti.
Alcune soluzioni come CORBA (si veda fig. 1.2) permettono di rea-
lizzare la comunicazione tra client e server passando attraverso un canale
comune chiamato ORB (Object Request Broker). Le applicazioni, anche se
1.1. DIFFUSIONE DELLE TECNOLOGIE DI COMUNICAZIONE 5
Figura 1.2: Client Server in Corba
implementate in differenti linguaggi, comunicano tra loro attraverso l’ORB
e ottengono la dichiarazione dell’interfaccia delle controparti con cui hanno
intenzione di instaurare una comunicazione. Ogni applicazione ha quindi
una descrizione scritta in un linguaggio indipendente dall’implementazione
che prende il nome di IDL (Interface Definition Language).
Si diffonde quindi il concetto di framework per rete aziendale che si
preoccupa di creare un medium comune di comunicazione tra le varie appli-
cazioni esistenti creando un livello di supporto su cui tutte le applicazioni
si appoggiano per comunicare tra loro. Le realizzazioni esistenti si differen-
ziano per come concettualmente ed implementativamente permettono di
raggiungere tale risultato.
In fig. 1.3 viene descritto il concetto di framework, il quale fornisce una
singola e unificata infrastruttura software che riduce il numero di prodot-
ti mirati all’integrazione, supporto e mantenimento degli altri applicativi
[GS02a].
I framework applicativi si propongono come livelli di astrazione su cui si
6 1. INTRODUZIONE AI WEB SERVICE
Figura 1.3: Generico Application Framework
possano costruire i server applicativi e gli strumenti per lo sviluppo di ap-
plicazioni. Il modello presentato in figura riassume le caratteristiche di un
generico framework applicativo il quale fornisce una serie di servizi di cui i
Web Service sono soltanto una parte.
In fig. 1.4 viene descritto invece un modello astratto di Application
Framework per IBM. Esso si diffonde come strumento finalizzato a cambiare
il modo in cui vengano gestiti i processi aziendali, permettendo l’evoluzio-
ne verso l’idea di e-business. I motivi che hanno spinto all’introduzione
del concetto di framework applicativi possono essere riassunti nei seguenti
punti: [IBM99]
• massimizzare la velocita` e semplicita` nello sviluppo e distribuzione di
applicazioni aziendali
• servire varie tipologie di client attraverso il supporto degli standard
di Internet
• assicurare la portabilita` verso differenti ambienti in risposta a diverse
esigenze di scalabilita` e Quality of Service
1.1. DIFFUSIONE DELLE TECNOLOGIE DI COMUNICAZIONE 7
Figura 1.4: Application Framework IBM
• Estendere la sicurezza, affidabilita` e scalabilita` delle applicazioni che
sono il cuore di molti processi aziendali
La comunicazione client-server viene quindi trasformata in una comu-
nicazione tra un client ed un Web Application Server realizzato su una
infrastruttura (framework) che fornisca determinate tipologie di servizi ac-
cessori (si veda fig. 1.4).
Il Web Application Server nel modello di framework di IBM, orchestra l’ac-
cesso ai dati aziendali da parte di piu` client e fornisce loro le informazioni
richieste attraverso il Web. Tale scelta permette sia di utilizzare standard
diffusi quali TCP/IP, HTTP e HTML, sia di mantenere con facilita` la con-
sistenza delle informazioni aziendali relegando l’accesso alle stesse al solo
Application Server.
Le applicazioni diventano di fatto web-based o Web Application, che si pro-
pongono come modello per fornire servizi attraverso la Rete.
Vengono inoltre identificate le seguenti componenti nella topologia di una
Web Application [IBM99]:
8 1. INTRODUZIONE AI WEB SERVICE
• I client, che accedono ai servizi attraverso Internet o reti locali sfrut-
tando i medesimi protocolli diffusi sulla Rete. Tale figura riveste un
ruolo di mediazione tra i servizi e gli utenti che intendono fruirli, per-
mettendo agli stessi di interagirvi e presentando in maniera opportuna
i risultati ottenuti
• I servizi infrastrutturali, i quali forniscono il Web Application Server
oltre a funzionalita` di sicurezza, replicazione, load balancing, caching
dei dati All’interno di questa tipologia di servizi vengono racchiusi an-
che i firewall che si frappongono tra il dominio aziendale e i client re-
moti a scopo di protezione da accessi non autorizzati alle informazioni
locali
• I Web Application Server, che orchestrano le richieste dei client ge-
stendo le risorse locali e restituendo informazioni attraverso pagine
Web
• i servizi esterni, che consistono di applicazioni gia` esistenti, non sem-
pre Web-based come anche servizi di aziende esterne con i quali avven-
gono interazioni
I client, che accedono al Web Application Server attraverso Internet o
una Intranet, sfruttano il medesimo protocollo basato sul Web e si scindono
in due tipologie:
• i client HTML, i quali eseguono richieste HTTP verso i Web Appli-
cation Server ed ottengono in risposta documenti HTML contenenti
le informazioni richieste. Tale soluzione pone tutti gli aspetti relativi
alla interfaccia verso l’utente all’interno della Server Web
• i client Application, i quali invece effettuano delle richieste attraverso
HTTP e ottengono, sempre attraverso il medesimo protocollo, dei
dati che vengono poi interpretati e formattati dall’interfaccia utente
sull’applicazione client stessa
Se la seconda soluzione permette di generare applicazioni client in vari
linguaggi, ad esempio Java, con uno stile e struttura da applicazione stand-
alone, i client HTTP dal canto loro vantano una maggiore semplicita`, limi-
tandosi ad essere interpretatori di documenti HTML, ovvero semplici Web
1.1. DIFFUSIONE DELLE TECNOLOGIE DI COMUNICAZIONE 9
Browser, alzando il livello di portabilita` dell’applicazione client-server stes-
sa ad un livello di utilizzazione indipendente da qualsiasi piattaforma e non
oneroso come la soluzione applicativa. Cio` ha permesso anche di favorire lo
sviluppo di web application accedibili anche da dispositivi con poche risorse
quali PDA o telefoni cellulari.
I Web Application Server invece sono stati introdotti come insieme di
interazioni tra un client ed un particolare sito Web [IBM99].
I framework applicativi individuano di fatto un insieme di linee guida e
di specifiche per la fornitura di piattaforme, strumenti e ambienti di pro-
grammazione per la progettazione, integrazione, gestione della sicurezza,
performance e affidabilita` di applicazioni distribuite [GS02a].
L’interazione tra client e l’Application Server si scinde nelle seguenti tre
sezioni:
• Modello, ovvero gli elementi che permettono di memorizzare e pro-
cessare le informazioni introdotte dall’utente attraverso il client. Que-
sta fase dell’interazione prende il nome di logica aziendale
• Vista, ovvero gli elementi che costruiscono le pagine HTML che
vengono inviate al client, curando quindi gli aspetti di stile e di
presentazione. Questa fase di interazione viene definita logica User
Interface
• Controllo, ovvero gli elementi che controllano altri elementi, come il
controllo dell’esecuzione di richieste HTTP, la selezione del corretto
modello ovvero del corretto insieme di elementi atti a gestire una
richiesta dell’utente e la scelta della corretta vista da utilizzare per la
formattazione dei risultati
I framework applicativi sono quindi una infrastruttura, sui cui vengono
fornite varie tipologie di servizi finalizzati a differenti scopi. Tra queste
tipologie di servizi, i Web Service, rivestono un ruolo di integrazione
tra server applicativi di piattaforme differenti come sara` possibile
comprendere nelle descrizioni successive. Nel par. 2.1.1 infine vengono
considerati piu` da vicino gli application framework, riassumendo principal-
mente le caratteristiche delle due architetture principali per applicazioni
10 1. INTRODUZIONE AI WEB SERVICE
client-server e web-based esistenti sul mercato : Microsoft .Net e Java 2
Enterprise Edition (J2EE).
Le problematiche aziendali nella coordinazione delle varie sezioni interne
e l’esigenza di far comunicare tali sezioni tra loro, sottopone gli sviluppatori
all’esigenza di favorire la comunicazione tra applicazioni differenti, spesso
sviluppate in linguaggi differenti e su sistemi operativi differenti, al fine di
facilitare la comunicazione intra-aziendale [LFA].
I Web Service si propongono di fatto come soluzione alla comunicazione
tra differenti framework per sopperire a soluzioni meno platform indipendent
come CORBA, ove la comunicazione tra differenti infrastrutture non ha di
fatto trovato una soluzione funzionale. Le soluzioni che verranno descritte
si propongono quindi per favorire il concetto di comunicazione interazien-
dale, favorendo l’idea di e-business tra aziende, spesso piu` noto come b2b o
business-to-business .
Cio` ha permesso dal punto di vista aziendale, di poter favorire la comunica-
zione tra applicazioni sia a livello intraziendale che a livello interaziendale.
Questo modo di vedere il business-to-business permette peraltro di rendere
dinamico il modo in cui ogni azienda possa gestire le sue componenti interne
e l’interfacciamento verso e dalle altre aziende.
L’esigenza di aziende che possano informatizzare i propri processi di svilup-
po cambiandoli dinamicamente nel tempo, ha dato un grosso impulso alla
creazione di tecnologie applicative capaci di riorganizzare quello che viene
usualmente definito il business flow [Sne01b] ovvero il modo in cui ogni
sezione di una azienda cooperi all’interno dell’organigramma complessivo
ma anche il modo in cui tali sezioni possano interfacciarsi con quelle di al-
tre aziende.
I Web Service si pongono come ultima soluzione nel campo della comunica-
zione interaziendale, promettendo la capacita` di permettere ad applicazioni
sviluppate in linguaggi tra loro differenti e su sistemi differenti, di potersi
scambiare informazioni attraverso computazioni distribuite. Tale tecnologia
si presenta come elemento per la realizzazione di una vera comunicazione
interaziendale, realizzata attraverso una comunicazione basata sul web. Nei
1.1. DIFFUSIONE DELLE TECNOLOGIE DI COMUNICAZIONE 11
prossimi paragrafi verra` delineata piu` precisamente questa nuova tecnolo-
gia e se ne daranno le motivazioni per cui tante aziende vi stiano investendo.
1.1.1 La necessita` di parlare una lingua comune
Ovviamente per realizzare una comunicazione tra due o piu` dispositivi, si
rende necessario parlare una medesima lingua. Tale intento viene realizzato
tramite un insieme di livelli che identificano le differenti esigenze necessarie
alla comunicazione interapplicativa. L’architettura dei Web Service e` una
composizione di differenti livelli, ognuno con un preciso ruolo e descritto at-
traverso linguaggi differenti. Tale visione a stack dei Web Service, permette
di vedere il loro sviluppo come estensioni successive di una base architet-
turale e lascia libere le singole aziende produttrici di tali architetture, di
formalizzarle in maniera differente basandosi su una struttura in cui ven-
gano riconosciuti: XML (eXtensible Markup Language) come linguaggio
unico per lo scambio di dati tra differenti applicazioni e SOAP (Simple
Object Access Protocol) per incapsulare le richieste e le risposte inviate
tra dispositivi. Sono stati inoltre definiti un insieme di linguaggi basati su
XML-Schema (si veda [DC01] e [HST01]) per descrivere la tecnologia dei
Web Service quali WSDL (Web Service Description Language) [Wil98] e per
la loro orchestrazione quali WSFL (Web Service Flow Language) [Ley01] di
IBM e XLANG [Tha01] di Microsoft.
L’uso di XML come linguaggio di scambio unico per i dati ha permesso
di standardizzare il modo in cui avvenga lo scambio di informazioni tra
differenti applicazioni. Il fatto che i Web Service siano una tecnologia che
permetta la comunicazione tra applicazioni indipendentemente da protocol-
li e sistemi operativi, ha permesso anche di favorire un aspetto importante
di tale tecnologia: l’automazione.
I Web Service sono di fatto pensati per favorire la comunicazione automati-
ca tra applicazioni in cui la componente umana possa anche essere assente.
Con tali presupposti si e` reso necessario rendere disponibili alle applicazioni
comunicanti un linguaggio comune per lo scambio dei dati (XML appunto)
e un metodo comune per l’incapsulamento di tali dati per l’invio di richieste
e risposte tramite protocollo HTTP (ruolo rivestito dal protocollo SOAP).
12 1. INTRODUZIONE AI WEB SERVICE
Nei prossimi paragrafi sara` descritta piu` dettagliatamente tale tecnologia e
ne studieremo l’architettura mentre nei paragrafi 2.1 e 2.1.1 verra` esaminata
l’infrastruttura applicativa sottostante.