Università degli Studi di Roma La Sapienza. Facoltà di Ingegneria

Università degli Studi di Roma La Sapienza Facoltà di Ingegneria Tesi di Laurea In Ingegneria Informatica PROGETTO, REALIZZAZIONE, SPERIMENTAZIONE E TUNING DI UN ORCHESTRATORE DI WEB SERVICE Relatore: Ing. Massimo Mecella Laureando: Adriano Bernardini (matr. 09102760) Anno Accademico 2003/2004

1

Ai miei genitori. 2

3

SOMMARIO INTRODUZIONE... 6 1 INTEGRAZIONE E COOPERAZIONE DI SISTEMI INFORMATIVI DISTRIBUITI... 9 1.1 I SISTEMI INFORMATIVI COOPERATIVI... 9 1.2 APPLICAZIONE DEL PARADIGMA CIS... 12 1.3 SCENARIO METODOLOGICO E TECNOLOGICO DI SUPPORTO AL CIS... 16 1.4 LA PROPOSTA ATTUALE PER I CIS: I WEB SERVICE... 19 1.5 ARCHITETTURA PER WEB SERVICE... 22 1.5.1 Web Service Description Language... 25 1.5.2 Web Service Transition Language... 27 1.5.3 The Simple Object Access Protocol... 30 1.5.4 Universal Description, Discovery and Integration... 32 2 FRAMEWORK ATTUALI PER LA COMPOSIZIONE DI WEB SERVICE... 36 2.1 IL PARADIGMA DEL SERVICE-ORIENTED COMPUTING... 36 2.1.1 Inter-Organizational workflow... 38 2.1.2 EBXML (Electronic Business using extensible Markup Language)... 41 2.1.3 Piattaforme e modelli di orchestrazione... 42 2.1.4 Web Service Componentization... 43 2.1.5 Web Service discovery and automatic composition... 45 2.2 UN FRAMEWORK PER ORCHESTRAZIONE DI WEB SERVICE... 46 2.3 MODELLO CONCETTUALE DEI WEB SERVICE... 49 2.3.1 Diagrammi UML per la rappresentazione di Web Service... 53 2.4 MODELLO PER ORCHESTRAZIONE DINAMICA... 55 2.5 LINKING DI WEB SERVICE... 59 2.5.1 Compatibilità e sostituibilità di Web Service... 61 3 TECNOLOGIE PER ORCHESTRAZIONE DI WEB SERVICE... 64 3.1 DISEGNO DEL FRAMEWORK PARIDE... 64 3.2 STANDARD EMERGENTI PER IL DISEGNO DI PROCESSI DI BUSINESS COOPERATIVI... 66 3.2.1 I primi lavori... 67 3.2.2 Business Process Execution Language for Web Service... 68 3.2.3 Web Service Choreography Interface... 70 3.2.4 Business Process Management Language... 71 3.2.5 Considerazioni conclusive sulle tecnologie proposte... 72 3.3 STRUTTURA GENERALE DI UN BPEL PROCESS... 73 3.3.1 I partner di un BPEL Process... 75 4

3.3.2 Message correlation... 76 3.3.3 Variabili nel BPEL Process... 78 3.3.4 Gestione delle eccezioni... 78 3.3.5 Attività primitive... 79 3.3.6 Le attività strutturate... 80 3.3.7 Conclusioni... 82 4 PROGETTO E SPERIMENTAZIONE DEL PROTOTIPO DI PARIDE... 84 4.1 PROGETTAZIONE DEI COMPONENTI DEL PROTOTIPO... 84 4.1.1 Architettura del prototipo... 88 4.2 PROPOSTA DI RIUSO: COLLAXA... 92 4.2.1 Architettura del Collaxa BPEL Server... 93 4.2.2 Realizzazione ed istanziamento di un processo BPEL con Collaxa... 97 4.3 DISEGNO DEL PROGETTO... 105 4.4 SPERIMENTAZIONE DELL ORCHESTRATORE DISTRIBUITO PARIDE... 114 4.4.1 Ambiente di esecuzione e obiettivi della fase di test... 114 4.4.2 Risultati e considerazioni... 117 5 INGEGNERIZZAZIONE ED AMPLIAMENTO DEL PROTOTIPO PARIDE... 122 5.1 COMPATIBILITÀ E SOSTITUZIONE DI WEB SERVICE... 122 5.1.1 Motore di compatibilità: riuso dell XMLEngine... 125 5.1.2 Realizzazione del modulo di compatibilità... 130 5.2 DELEGA DI RESPONSABILITÀ DI UN PROCESSO... 135 5.2.1 Ampliamento del Distributed Orchestration per la gestione della Delegation... 137 6 METODOLOGIA PER IL DISEGNO E LA REALIZZAZIONE DI UN PROCESSO COOPERATIVO DISTRIBUITO... 143 6.1 PROGETTAZIONE DEL PROCESSO COOPERATIVO DISTRIBUITO... 143 6.2 TRADUZIONE DELL ORCHESTRATION NET IN BPEL... 144 6.3 DEPLOY DEL PROCESSO COOPERATIVO DISTRIBUITO... 154 CONCLUSIONI... 155 BIBLIOGRAFIA... 157 5

INTRODUZIONE Con l affermarsi di Internet e dell Information and Communication Technology (ICT), la comunicazione e lo scambio di risorse tra sistemi diversi che collaborano per il raggiungimento di un obiettivo comune, è un esigenza sempre più diffusa in particolare nel mondo dell ebusiness e dell egovernment. In questo contesto si inserisce PARIDE (Process based framework for Orchestration of dinamyc E-service), un approccio metodologico con lo scopo di definire e delineare un framework per l integrazione di sistemi distribuiti eterogenei basato sui processi/servizi. Gli elementi fondamentali che lo caratterizzano sono la definizione di un modello concettuale e di un architettura di riferimento per la cooperazione tra i vari sistemi in rete basata sull orchestrazione di WS, cioè coordinazione e composizione di servizi offerti on-line. Alla luce di quanto esposto la realizzazione e lo sviluppo di PARIDE si sono concretizzati inizialmente attraverso una precedente tesi [rif. 56] che ha raffinato il modello concettuale, e ha progettato ed iniziato la realizzazione di un un prototipo in grado di eseguire orchestrazione peer-topeer di WS. La capacità di comporre e coordinare Web Service in modo distribuito deriva dalle esigenze d implementare processi cooperativi direttamente applicabili al mondo dell ebusiness e dell egovernment; in particolare in quest ultimo scenario applicativo le procedure da automatizzare sono spesso frammentate in tanti workflow controllati da diverse organizzazioni per motivi burocratici o economico/amministrativi. Attualmente in commercio sono presenti diversi orchestrator capaci di interoperare con i WS, ma nessuno per ora supporta l esecuzione distribuita di un processo cooperativo. Per questo la precedente tesi si è proposta di contribuire allo sviluppo di PARIDE estendendo un orchestrator commerciale per risolvere i problemi di distribuzione delle responsabilità legati all egovernment. Eseguire cooperazione richiede al sistema di essere capace di riflettere sia i cambiamenti decisi per il miglioramento delle sue prestazioni, sia i cambiamenti delle pratiche organizzative, perciò le caratteristiche di dinamicità e flessibilità sono fondamentali in un contesto come quello a cui PARIDE intende rivolgersi. Quindi attraverso un analisi più approfondita dei processi che il sistema dovrebbe automatizzare, la presente tesi si è proposta di completare il il progetto e la realizzazione del precedente prototipo, al fine di produrre una versione ingegnerizzata capace di supportare una tipologia più ampia di processi distribuiti, e la sostituzione dinamica di servizi compatibili durante l esecuzione di un processo cooperativo che li veda coinvolti. L ingegnerizzazione si è concentrata 6

inizialmente sulla revisione del prototipo del precedente lavoro al fine di renderlo stabile, fino ad arrivare ad una fase di sperimentazione tesa a valutare il dazio da pagare in termini di prestazioni di un processo distribuito rispetto ad uno centralizzato. Dai risultati dei test ci si attendeva, infatti, un calo delle performance dovuto alla scelta di rendere dinamica la distribuzione di un processo cooperativo, ovvero la possibilità di scegliere a tempo di esecuzione l organizzazione destinataria del passaggio di responsabilità dell istanza in fase di processamento che, se da un lato permette al sistema di guadagnare in flessibilità, di contro, rende necessaria l aggiunta di nuovi livelli applicativi per la sua gestione che rallentano inevitabilmente l esecuzione del processo. Nel mondo dell ebusiness e dell egovernment spesso sono presenti processi in cui siano previsti dei sottoworkflow da eseguire in parallelo su organizzazioni differenti; il semplice pasaggio di responsabilità non poteva essere applicato a questo tipo di processi, quindi è stato necessario prevedere un ulteriore meccanismo di distribuzione, quale la delega di responsabilità, sia a livello metodologico che a livello progettuale, al fine di permettere, unitamente al passaggio di responsabilità, l automatizzazione di qualsiasi procedura organizzativa/amministrativa. Infine per realizzare un prototipo che sia completamente flessibile e dinamico, è stato necessario progettare ed implementare il Compatibility Manager, sulla base di un algoritmo presentato in [rif.57]; tale componente del prototipo è incaricato della sostituzione dinamica di Web Service compatibili durante l esecuzione di un processo; infatti in una realtà sempre aperta all ingresso di nuovi soggetti, la concorrenza che può nascere tra servizi alternativi che sono in grado di inserirsi in qualunque momento nell ambito di un processo cooperativo esistente, è il motore del miglioramento continuo. La tesi sarà suddivisa in sei capitoli strutturati nel seguente modo: Capitolo 1: dopo un introduzione al paradigma dei CIS e alle realtà di applicazione, viene presentata una panoramica delle metodologie e tecnologie proposte. In particolare ci sarà una approfondita descrizione della soluzione basata su Web Service, e si esploreranno le tecnologie e gli standard fondamentali che ci permettono di interoperare con loro. Capitolo 2: illustrerà il paradigma del Service-Oriented Computing per eseguire composizione di Web Service, e una panoramica dei principali sviluppi che la sua applicazione ha prodotto. Infine viene descritto il framework PARIDE come un primo approccio esaustivo ai problemi legati al SOC e viene fornita la descrizione del suo modello concettuale. 7

Capitolo 3: darà una descrizione dell architettura di PARIDE e una panoramica delle tecnologie e delle proposte più attuali e mature in ambito di coordinamento di Web Service, soffermandoci sullo standard BPEL4WS. Capitolo 4: si dedicherà alla riprogettazione del prototipo, con una sostanziale modifica del modulo di compatibilità ed un ampliamento di quello relativo all orchestrazione distribuita, sottolineando di volta in volta con cura le scelte progettuali e le motivazioni che le hanno determinate; in ultima istanza, presenteremo i risultati della sperimentazione dell applicazione attraverso un analisi delle prestazioni del sistema durante l esecuzione distribuita di un processo rispetto a quella centralizzata. Capitolo 5: descrive in dettaglio la realizzazione e implementazione dei moduli del prototipo riproggettati nel precedente capitolo. Capitolo 6: darà la definizione di metodi e tecniche per lo sviluppo di un processo cooperativo distribuito, nel quale siano anche previste ramificazioni di sottoprocessi paralleli. Saranno infine discusse le conclusioni tratte sulla base del lavoro proposto e verranno indicate le future direzioni di ricerca basate sull approfondimento e lo sviluppo delle tematiche presentate. 8

1 INTEGRAZIONE E COOPERAZIONE DI SISTEMI INFORMATIVI DISTRIBUITI In questo capitolo parleremo di ebusiness ed egovernment, applicazioni dell ICT (Information and Communication Technology) alle realtà rispettivamente del mercato economico e della pubblica amministrazione, come principali scenari applicativi del nostro progetto, e parleremo del CIS (Cooperative Information System) come l area di ricerca a cui la presente tesi intende dare il suo contributo. Per completezza si darà una breve descrizione delle proposte già presenti, delle idee positive a cui il progetto ha aderito, dei problemi che ha tentato di superare e quelli che tutt ora restano irrisolti. Infine identificando nei Web Service la proposta attuale ai problemi dei CIS, verrà fornita una panoramica delle tecnologie e degli standard più diffusi al momento. 1.1 I Sistemi Informativi Cooperativi La comunicazione e lo scambio di risorse tra sistemi diversi che collaborano per il raggiungimento di un obiettivo comune, è un esigenza diffusa in molti ambiti reali. Vari esempi si trovano nella produzione industriale, dove ogni azienda ha necessità di collaborare con altri partner offrendo e richiedendo servizi al fine di soddisfare le richieste del mercato, oppure nell ambito dell amministrazione pubblica e nel servizio sanitario nazionale in cui vari uffici o dipartimenti devono scambiarsi dati sui cittadini per poter offrire un servizio efficiente. Quanto descritto è lo scenario in cui s inserisce la definizione del Cooperative Information System (CIS), ossia, un Sistema Informativo su larga scala che interconnette sistemi di differenti organizzazioni autonome, geograficamente distribuite e che cooperano e condividono risorse (dati e/o servizi) per il raggiungimento di un obiettivo comune. I CIS pongono alla base della loro funzionalità la natura collaborativa delle interazioni tra i diversi sistemi informativi che li costituiscono. Tale collaborazione, presuppone la capacità di scambiare informazioni e di mettere le proprie funzionalità e risorse al servizio degli altri sistemi. Supportare la cooperazione richiede al sistema di essere capace di riflettere sia i cambiamenti decisi per il miglioramento delle sue prestazioni sia i continui cambiamenti delle pratiche organizzative. 9

Il problema diventa quindi quello di costruire sistemi informativi che siano in grado di condividere gli obiettivi dell ambiente comune in cui sono immersi (altri sistemi informativi, agenti umani, ) quando l ambiente stesso è soggetto a continue evoluzioni. Un sistema informativo cooperativo non è più considerabile come una semplice collezione di basi di dati, applicazioni e interfacce, ma piuttosto diventa un architettura che assicura la consistenza fra una varietà di sistemi automatizzati, gruppi di fruitori di servizi e obiettivi di organizzazioni che evolvono nel tempo. Sono quindi la dinamicità e la duttilità, insieme al presupposto d interoperabilità, le chiavi per il successo di un sistema informatico cooperativo. Riassumendo il concetto dei CIS è definito come segue [rif.1]: un vasto numero di sistemi cooperanti, distribuiti su una vasta e complessa rete di comunicazione, che lavorano insieme cooperativamente, richiedendo e condividendo informazioni, vincoli e obiettivi.. Per lo sviluppo di sistemi informativi cooperativi, si possono distinguere quattro principali approcci: Data Integration: integrazione dei dati e dei loro schemi concettuali, con particolare attenzione alla qualità dei dati trattati [rif.2] Sistemi e metodologie agent-based: studio di sistemi ad agenti intelligenti e mobili [rif.3] Business Process Coordination: sistemi per il coordinamento di processi [rif.4] Service-based System: sistemi service-oriented [rif.5] È su questi ultimi due aspetti che intendiamo concentrarci, definendo innanzi tutto i concetti fondamentali ad essi legati. Definiamo allora in modo rigoroso il Business Process come [rif.1]: un unità di lavoro persistente avviata da un evento di business come una richiesta di pagamento, una fattura o una richiesta di trasferimento fondi. Il processo è guidato da regole di business che avviano task e sotto-processi, la cui esecuzione è assegnata a risorse, rappresentate da organizzazioni in grado di giocare uno specifico ruolo all interno del processo stesso 10

Trattasi quindi dell astrazione di un complesso processo cooperativo che coinvolge più organizzazioni che cooperano tra loro offrendo dei servizi e condividendo risorse per il raggiungimento di un obiettivo comune. Inizialmente i processi informativi che sono stati oggetto di automazione, ovvero di sviluppo di procedure e applicazioni informatiche, erano ristretti a quelli relativi al flusso di attività all interno di una singola organizzazione tra i livelli operativo, organizzativo e gestionale, e prima ancora alla sequenza di attività relative al solo piano operativo. In seguito con un mercato sempre più esigente e con l avvento di Internet e delle tecnologie dell ICT, che hanno cancellato le difficoltà di comunicazione imposte dai limiti geografici, i processi di business si sono estesi alla cooperazione inter-organizzazioni. La tecnologia quindi può essere usata per (semi)automatizzare macro-processi che coinvolgono più imprese/organizzazioni attraverso applicazioni cooperative. Ma come può avvenire ciò senza richiedere cambiamenti radicali alle realtà organizzative interessate? Utilizzando i Service-based System [rif.5]: è un Sistema Informativo che si interfaccia alla realtà esterna offrendo dei servizi e nascondendo la loro realizzazione Il fatto di avere organizzazioni loosely-coupled, permette di apportare cambiamenti interni alla organizzazione mantenendo invariata l interfaccia dei servizi offerti, senza impattare quindi sul macroprocesso in cui sono coinvolte. Inoltre se a seguito di una fase di re-engeneering dei processi interni alla organizzazione sono disponibili nuovi servizi, il macro-processo può essere modificato ottenendo un globale e più sostanziale miglioramento, in sostanza un radicale re-engeneering del processo cooperativo[rif.6]. Quello che i CIS mettono a disposizione è un paradigma di cooperazione aperta basato sui processi/servizi, in cui nessun soggetto è indispensabile, perché tutti sono rilevanti in uguale misura, ma possono essere, in qualche modo, sostituiti. La capacità di gestire il cambiamento, di cui si è parlato, deve potersi intendere anche in questo senso, perché cambiare può voler dire non solo modificare i propri obiettivi, ma anche modificare i propri partner, sceglierne di migliori o semplicemente sceglierne di diversi se quelli abituali sono indisponibili, senza che questo vada ad inficiare in alcun modo il macro-processo in esecuzione. È questa realtà più dinamica a consentire il processo di miglioramento continuo, perché stimola la competizione e permette l ingresso nel 11

mercato di soggetti sempre nuovi, quando questi siano in grado di offrire un servizio migliore rispetto ad altri, a tutto vantaggio dei clienti di tali servizi. 1.2 Applicazione del paradigma CIS Il paradigma CIS trova la sua più naturale e concreta applicazione nelle realtà del mercato economico-commerciale e della pubblica amministrazione; in particolare la prima punta sull ebusiness, mentre la seconda sull egovernment, entrambe sempre più all attenzione dei ricercatori del CIS grazie allo sviluppo di tecnologie di rete ed al sempre maggiore affermarsi di Internet. L ebusiness è l applicazione dell ICT per condividere informazioni, erogare servizi fra diversi soggetti legati da relazioni commerciali ed economiche, per ottenere prodotti/servizi più complessi e con un maggior valore aggiunto, spinti da un mercato sempre più esigente e dall obiettivo finale della massimizzazione dei profitti. Anche le medio-piccole imprese hanno fatto proprie le soluzioni offerte dall ebusiness per poter sopravvivere in una realtà commerciale che le vedeva sfavorite rispetto ad organizzazioni di grandi dimensioni, per rispondere soprattutto a domande del mercato che da sole non avrebbero potuto soddisfare. Le modalità con cui le organizzazioni si sono interfacciate al mondo esterno nell ebusiness sono state le seguenti (vedi fig 1.1): Business to Consumer (B2C): in questa prima fase le organizzazioni hanno sfruttato il web per creare dei magazzini virtuali che facilitassero l acquisto di beni e di servizi da parte dei consumatori. Questo ha permesso un taglio netto dei costi di distribuzione nella Value Chain [rif.7], con conseguente abbassamento dei prezzi di vendita dei prodotti/servizi e l instaurazione di un rapporto diretto produttore/utente finale. Business to Business (B2B): in questa seconda fase le interazioni commerciali si sono estese alle imprese, per le quali si sono utilizzati applicazioni scritte ad hoc per l automazione di un particolare processo di business tra due organizzazioni, tipicamente quello di fornitura. e-community: il terzo passo è stato quello di estendere la collaborazione tra le imprese di una stessa area di business via Internet, per i principali processi di core business, 12

come quelli di gestione degli ordini, di gestione dei magazzini, i customer services fino anche alla realizzazione fisica dei prodotti. Trading Partner Network (TPN): nella quarta si è introdotta l interazione automatizzata (e trasparente) non solo tra partner di una stessa e-community, ma anche tra partner di aree di business differenti. Figura 1-1 Nella realtà italiana, una considerevole percentuale di tali soggetti è aggregata nella forma di distretti, cioè di raggruppamenti geografici d imprese (spesso piccole e medie) che contribuiscono, attraverso una catena di fornitura comune, alla produzione di beni/prodotti. Quindi per le aziende inserite all interno dei distretti, il paradigma dell ebusiness si concretizza nella possibilità di costruire un nuovo sistema di relazioni tra fornitori, produttori e canali di distribuzione, non più basato solamente sulla dislocazione geografica e/o su relazioni personali, ma sull utilizzo strategico dell ICT, permettendo in ultima analisi la creazione di Distretti Virtuali. L esperienza nel mondo delle imprese commerciali ha indotto a pensare di poter applicare il paradigma dei CIS al piano previsto per la pubblica amministrazione in cui tutti gli uffici amministrativi possano interagire come partner di una stessa e-community aperta anche ad altri soggetti non necessariamente istituzionali. Tale piano è indicato con il termine di egovernment cioè l utilizzo delle moderne tecnologie ICT nel processo di ammodernamento delle amministrazioni del Paese finalizzate al compimento delle seguenti categorie di azioni [rif.8,9]: 1. le azioni di informatizzazione dirette a migliorare l efficienza operativa interna delle singole amministrazioni; 13

2. le azioni dirette ad informatizzare l erogazione dei servizi ai cittadini e alle imprese che spesso implicano una integrazione tra i servizi di diverse amministrazioni; 3. le azioni dirette a consentire l accesso telematico degli utilizzatori finali ai servizi della pubblica amministrazione e alle sue informazioni. Il Piano di Azione per l egovernment, presentato nel corso dell anno 2000 [rif.8], si propone di coinvolgere tutte le amministrazioni sia centrali che locali e tutte le istituzioni del Paese: le regioni, le province, i comuni, le scuole, gli ospedali, le ASL, i centri per l impiego, le camere di commercio, ecc.; in pratica ogni ente od organizzazione cui siano delegate funzioni di servizio pubblico alle persone o alle imprese. L infrastruttura tecnologica abilitante tale piano è rappresentata dalla Rete Unitaria per la Pubblica Amministrazione (RUPA), uno tra i risultati più importanti conseguiti dall AIPA, l Autorità per l Informatica nella Pubblica Amministrazione [rif.10]. L'obiettivo della Rete Unitaria [rif.11,12] consiste nel garantire a qualunque utente della rete, purché autorizzato e in condizioni di sicurezza, di poter accedere ai dati e alle procedure residenti nei sistemi informativi automatizzati della propria e delle altre amministrazioni, indipendentemente dalle reti attraversate e dalle tecnologie adottate dai singoli sistemi informativi. Il piano propone una nuova visione dei servizi al cittadino, per cui questo ultimo: a) non dovrà più sapere come lo Stato è organizzato o a quale amministrazione si deve rivolgere per uno specifico servizio; b) potrà richiedere servizi esclusivamente in base alle proprie esigenze indipendentemente da ogni vincolo di competenza amministrativa, territoriale o di residenza; c) non dovrà più fornire all amministrazione cui si rivolge alcuna informazione che lo riguarda e che sia già in possesso di una altra amministrazione dello Stato. Per la realizzazione di questa visione è necessario che tutte le Amministrazioni e gli Enti siano dotati di sistemi informativi in grado di erogare servizi direttamente ai sistemi informatici delle altre amministrazioni. Inoltre è necessario che la rete globale sia una rete tra pari, senza gerarchie che riflettano sovrastrutture istituzionali od organizzative: deve essere solo il ruolo che l amministrazione gioca nel confronti del cittadino a fare la differenza tra i soggetti coinvolti nella cooperazione; sono le amministrazioni locali, in accordo con il decentramento amministrativo, ad assumere il ruolo di sportello per l accesso ai servizi pubblici, cioè di front-office, mentre le 14

amministrazioni centrali, ma anche alcune locali come ad esempio le anagrafi, svolgono un ruolo di back-office. Il ruolo delle amministrazioni di front-office è chiave nella realizzazione del modello che impone di pensare per processi : sono queste amministrazioni ad offrire al cittadino il servizio/processo, che si realizza attraverso la cooperazione e l integrazione dei servizi delle amministrazioni di back-office, ma che proprio per questo può essere rimodellato ed adattato sulle esigenze del cliente senza che questo se ne accorga e senza che il sistema complessivo debba mutare radicalmente. Dunque due mondi estremamente diversi, quello dell ebusiness e quello dell egovernment presentano in realtà problematiche simili che possono essere risolte con strumenti analoghi: ulteriori conferme arrivano dalle riflessioni che è necessario fare su un altro aspetto. Si è parlato prima del processo di miglioramento continuo di un macro-processo, perseguibile attraverso la scelta, momento per momento, del partner migliore per le proprie transazioni: questo tipo di scelta non sarebbe propriamente possibile nell ambito della Pubblica Amministrazione, dove i soggetti con i quali interagire sono definiti, in linea di principio, dalla legge. In realtà, il pensare l Amministrazione come una e-community e progettare la cooperazione incentrandola sui processi/servizi, offre a ciascuna organizzazione la possibilità di scegliere il servizio migliore, dal punto di vista di esigenze, ad esempio, di qualità o tempestività, purché sia compatibile con le specifiche del processo che l organizzazione esegue. Pensiamo ad esempio alla necessità di recuperare i dati anagrafici di un cittadino da parte di un ente: quest ultimo potrebbe scegliere, a tempo di esecuzione, come organizzazione servente quella che garantisca il miglior grado di aggiornamento possibile per quei dati; nulla vieta che una successiva richiesta sia soddisfatta da un altra organizzazione, e così via. Quindi il processo di miglioramento continuo può realizzarsi anche in questo scenario, perché i progressi nella qualità dei servizi offerti da ciascuna organizzazione, che deve ritenersi in concorrenza con le altre, si riflettono inevitabilmente sulla qualità del servizio complessivo offerto al cittadino/cliente. 15

1.3 Scenario Metodologico e Tecnologico di supporto al CIS Le soluzioni prima metodologiche e poi tecnologiche nello sviluppo dei sistemi informativi comunicativi (CIS) hanno puntato soprattutto a risolvere i problemi legati all integrazione a livello di logica applicativa dei prodotti/servizi offerti dalle organizzazioni, in quanto i problemi tecnologici legati all automazione dei processi di business riguardano la comunicazione e la collaborazione tra applicazioni distribuite. Non bisogna dimenticare, infatti, che proprio a livello di logica applicativa ciascuna organizzazione può rivendicare la propria unicità, può far valere le differenze che la portano a livelli di eccellenza, o meno, nel confronto con i propri concorrenti. Integrare sistemi diversi non vuol dire annullarne le individualità, e uniformare indiscriminatamente i processi di business di ognuno, ma sfruttarne appieno le potenzialità per il raggiungimento di un obiettivo comune, per la realizzazione, coordinata e collaborativa, delle best practices rispetto al mercato di interesse. Il primo approccio metodologico all integrazione venne sostanzialmente incentrato sulla comunicazione punto-punto tra le applicazioni interessate alla collaborazione e allo scambio di informazioni, secondo il paradigma client/server. Il limite di tale approccio divenne presto evidente nel momento in cui il numero dei soggetti coinvolti nel processo aumentava; infatti per ogni coppia di applicazioni che vogliano interagire tra loro risulta necessario programmare due interfacce distinte, quindi N applicazioni interagenti comportano l implementazione di N(N-1)/2 interfacce. Applicazione A A-C A-D A-B Applicazione B B-A B-D B-C C-A C-B Applicazione C C-D D-A D-C D-B Applicazione D Figura 1.2 Comunicazione punto-punto 16

È immediato concludere che la complessità del sistema risulta ben presto inaccettabile al crescere del numero di soggetti interessati a cooperare, in particolar modo dal punto di vista della manutenzione e della scalabilità. La soluzione che ha permesso di diminuire tale complessità architetturale prevede invece che le applicazioni interagiscano per mezzo di uno strato intermedio di software, detto middleware, che funge da vera e propria interfaccia universale per tutte le applicazioni che vi si appoggiano. La presenza di questa piattaforma comune di interazione consente di ridurre drasticamente il numero di interfacce che è necessario sviluppare e mantenere: per N applicazioni interagenti sono sufficienti solo 2N interfacce, e per ogni applicazione nuova o cambiata è sufficiente operare su solo 2 interfacce distinte. Applicazione A Interfaccia di A Applicazione B Interfaccia di B MIDDLEWARE Interfaccia di C Interfaccia di D Applicazione C Applicazione D Figura 1.3 - Middleware Negli anni l architettura di riferimento per l implementazione delle piattaforme di middleware è cambiata e si è notevolmente evoluta, venendo incontro alle sempre crescenti necessità di riduzione della complessità e ampliamento della gamma di servizi da mettere a disposizione. Le principali architetture middleware che si sono affermate sul mercato sono le seguenti: RPCs (Remote Procedure Calls): permette che l invio di una richiesta da un client verso un server avvenga come se fosse una normale chiamata locale di procedura. L interazione è bloccante, cioè il processo client viene sospeso finché la procedura chiamata non termina. MOM (Message Oriented Middleware): consente a client e server di comunicare scambiandosi generici messaggi attraverso code gestite in modo non bloccante. 17

Client e Server possono quindi essere operativi in tempi differenti, garantendo quindi un grande disaccoppiamento ed indipendenza. Distributed Objects: permette ad oggetti remoti di comunicare scambiandosi messaggi. I componenti essenziali di tale architettura sono un ORB (Object Request Broker) che trasferisce le richieste e le risposte tra oggetto client ed un oggetto server, ed un repository per la descrizione di tutti gli oggetti disponibili, utilizzato dall ORB per trovarli sulla rete. Database Oriented: permette l accesso a più basi di dati remote e gestite da differenti DBMS (DataBase Management System) relazionali in modo trasparente. Le piattaforme tecnologiche che sono state create per implementare middleware sono in parte o completamente la sintesi delle architetture esposte, in quanto ne riprendono le caratteristiche salienti. Tra quelle più note annoveriamo: JAVA RMI: permette l invocazione remota di metodo tra oggetti Java, i quali sono resi disponibili attraverso un RMI-Registry, secondo l architettura middleware delle Remote Procedure Call descritta sopra. CORBA: è una specifica che fornisce dei meccanismi che permettono l interoperabilità tra sistemi eterogenei mediante l astrazione di oggetto remoto; in particolare ciascun oggetto CORBA è definito dalla sua interfaccia espressa con il linguaggio dichiarativo IDL (Interface Definition Language) ed identificato da un riferimento IOR (Interoperable Object Reference) che mantiene le informazioni di indirizzamento dell oggetto; tali informazioni sono gestite dall Object Adapter e dall ORB (Object Request Broker)..NET: è un architettura che permette l interoperabilità tra componenti software, che possono essere implementati in qualsiasi linguaggio di programmazione e sono definiti attraverso le loro interfacce ciascuna delle quali ha un proprio identificativo (IID); tali interfacce sono generate in maniera dichiarativa attraverso il linguaggio MIDL (Middleware Interface Definition Language). J2EE: è un architettura di riferimento per lo sviluppo di applicazioni distribuite a tre livelli, definisce tecnologie ed API interoperabili tra loro (EJB, JSP, Servlet, 18

JDBC, JMS, JNDI, ), inoltre fornisce un ambiente di esecuzione omogeneo (Container) per le tecnologie incluse nello standard. I middleware sopra descritti sono comunque rimasti elusivi di fronte al problema principale nell industria che è quello di integrare applicazioni informatiche sviluppate in maniera indipendente: infatti, ciò ha portato ad una situazione in cui esiste un altissimo numero di tecnologie eterogenee reperibili sul mercato, e per questo difficilmente interoperabili. La più grande debolezza delle soluzioni offerte dalle architetture CORBA e DCOM per esempio, è che sono pensate per far comunicare sistemi distribuiti secondo il paradigma Server to Server, e quindi poco flessibili e duttili verso una struttura di tipo Client/Server. Inoltre prese singolarmente, CORBA è una specifica, di cui quindi ne esistono diverse implementazioni non omogenee tra loro, e per di più, è legata ad un linguaggio di programmazione Java (come J2EE), mentre DCOM, anche se potenzialmente multi-piattaforma, in realtà è un middleware proprietario. Come già previsto dal Pennine Group nel 1999 [rif.13] lo sviluppo di nuove architetture basate sulla programmazione ad oggetti ed a componenti non avrebbe garantito progressi e quindi non avrebbe avuto futuro nel campo del software. Piuttosto essi vedevano un futuro in cui gli sviluppatori avrebbero cambiato radicalmente modo di concepire il software: non più software come semplice applicazione, ma piuttosto come un servizio che implementa alcune funzionalità richieste dall utente. Tale visione è un contributo vitale al corrente modo di pensare circa lo sviluppo e la distribuzione del software che si sta affermando in parte con l iniziativa dei Web Service. 1.4 La proposta attuale per i CIS: i Web Service I Web Service sono applicazioni distribuite che espongono le funzionalità di servizi di business attraverso protocolli standard su Internet. Essi sono potenzialmente il mezzo per risolvere le problematiche inerenti i sistemi informativi cooperativi; infatti posseggono le caratteristiche di interoperabilità, incapsulamento ed accessibilità. L interoperabilità dei WS è soprattutto garantita dalle scelte sulla modalità di comunicazione: infatti i WS dialogano attraverso messaggi testuali basati sullo standard XML (extensible Markup Language), e viaggiano in Internet sfruttando i protocolli standard di rete (HTTP, MIME, ecc ). 19

Per questo i WS possono essere visti come un salto rivoluzionario e non semplicemente un evoluzione nell ambito dei CIS. Di recente molte tecnologie sono state classificate come Web Service Based, anche se in realtà non lo sono totalmente (CORBA, CGI Scripting, J2EE). La differenza sostanziale sta nella standardizzazione, ovvero nella scelta di usare XML in quanto linguaggio non proprietario e accettato ormai dalle maggiori firme tecnologiche. Infatti XML vanta le proprietà di essere: Indipendente dalla visualizzazione. Strutturato: sia sintassi che semantica possono essere validate. Può rappresentare dati: i dati provenienti da più sorgenti possono essere mappati su documenti XML che ne descrivono lo schema, ed integrati in un unico documento (ad es. integrazione di basi di dati). Versatile: componenti basati su tecnologie diverse possono comunicare tra loro attraverso protocolli ASCII descritti in XML. I WS sono quindi l implementazione di funzionalità offerte all esterno tramite Internet che permettono agli utenti di accedere a dei servizi e raggiungere degli obiettivi senza conoscere come in realtà tutto ciò è realizzato a livello di logica applicativa. Per questo i WS godono delle seguenti caratteristiche, tra cui alcune già citate [rif.14] : XML based: XML è usato per rappresentare i dati, per supportare le tecnologie per il trasporto dei dati stessi, ed è utilizzato anche per descrivere come poter interoperare con i WS. Loosely coupled (debolmente accoppiato): un utente di un WS non è vincolato direttamente ad esso; l interfaccia del WS può cambiare nel tempo senza compromettere l abilità del cliente di interagire con esso. Al contrario un sistema strettamente accoppiato implica che le logiche del client e del server siano molto vincolate l una all altra, cioè i cambiamenti effettuati ad una interfaccia implicano che anche l altra sia aggiornata. Quindi adottare un architettura loosely coupled genera sistemi software più flessibili e versatili, e permette di integrare tra loro sistemi differenti in maniera agevole. Incapsulamento: l implementazione della logica applicativa dei WS è trasparente all esterno. Ciò permette ai WS di poter essere implementati in qualsiasi linguaggio 20

di programmazione e di essere anche indipendenti dalla piattaforma di utilizzo in quanto sono esposti all esterno attraverso interfacce che permettono l accesso al servizio. Interazione bloccante o non bloccante: la sincronizzazione è riferita alla tipologia di binding del client all esecuzione del servizio. In una invocazione sincrona il client si blocca ed aspetta che il WS completi la sua elaborazione prima di continuare. Nelle operazioni asincrone al contrario, il cliente può invocare un servizio e procedere poi all esecuzione di altre operazioni ed, in un momento successivo, richiedere il risultato prodotto dall invocazione di quel servizio. La capacità di essere sia bloccante che non bloccante è una delle chiavi alla base dei sistemi loosely-coupled. Supporta RPC: i WS permettono ai client di invocare procedure, funzioni e metodi su oggetti remoti usando protocolli XML-based. Le procedure remote indicano i parametri di input e di output che i WS devono supportare. Lo sviluppo a componenti attraverso l Enterprise JavaBeans e.net Components ha visto crescere il suo ruolo all interno delle architetture software; entrambe le tecnologie sono distribuite ed accessibili attraverso meccanismi di RPC. Un WS supporta RPC attraverso i servizi che fornisce in modo equivalente ai tradizionali componenti o traducendo le invocazioni entranti in invocazioni ai componenti EJB o.net. In questo modo integra tecnologie all avanguardia e largamente diffuse, favorendo così il suo successo a la sua utilizzazione. Supporta scambio di documenti: la scelta dei WS di usare messaggi formattati in XML per comunicare ha favorito la capacità di scambiare non solo semplici dati, ma anche complessi documenti; infatti XML permette di rappresentare sia informazioni semplici quali, indirizzi, nomi, ecc.., sia libri interi e documenti complessi. Questa possibilità dei WS di supportare lo scambio trasparente di documenti gli conferisce una marcia in più nel mondo dell integrazione di business. Per tutti questi motivi i WS possono essere definiti come i componenti più flessibili e pervasivi del momento, oltre che per la loro facilità di componibilità e riusabilità. 21

1.5 Architettura per Web Service Con il termine Service Oriented Architecture (SOA) si definisce un architettura per la gestione delle interazioni con i WS, rappresentata in fig. 1-2, all'interno della quale si possono distinguere tre attori fondamentali: Description Language Publish() Service Provider Describe() Orchestration Language Service Broker Repository Unpublish(), Update() Discovery and Publish Language Discover() Invoke() Service Requestor Figura 1-2 - SOA Service Provider: entità che realizza e mette a disposizione un servizio. Tramite l'operazione di publish il servizio viene 'pubblicizzato ', cioè le caratteristiche del servizio realizzato vengono memorizzate all'interno di un repository accessibile pubblicamente. Il Service Provider rimane quindi in attesa che un cliente (utente umano e/o applicazione) richieda tale servizio. Service Broker: si occupa della gestione del repository, permettendo ai clienti di ricercare un servizio (operazione di discover) sulla base delle caratteristiche con il quale è stato definito e memorizzato (operazione di publish) dal provider. Permette inoltre la modifica (operazione di update) e anche l eliminazione di servizi già pubblicati (operazione di unpublish). Il Service Broker può seguire politiche di controllo degli accessi sulle interrogazioni, tali da limitare la visibilità sui servizi inseriti. Service Requestor: è il potenziale cliente in cerca di un servizio. A tale scopo, tramite la primitiva di discover, interagisce con il Service Broker per ottenere informazioni sul servizio più adatto ai propri obiettivi. Una volta individuato, si collega al Service 22

Provider corrispondente (operazione di invoke) ed inizia a fruire del particolare servizio (operazione di use). Oltre a queste figure fondamentali un framework di web service prevede un set di operazioni base da cui non è possibile prescindere: describe, publish, unpublish, discover and invoke. Il ruolo del Service Broker rappresenta il fulcro fondamentale dell intera architettura e nello stesso tempo la componente più innovativa. La sfida principale raccolta dai Web Service è quella di consentire l evoluzione dei sistemi object-oriented verso sistemi di servizi, in cui sia possibile la cosiddetta just-in-time integration, ossia la capacità per le applicazioni di interagire tra loro scoprendosi a tempo di esecuzione. Nel disegnare un processo cooperativo, dovrebbe essere necessario, dunque, preoccuparsi solamente di individuare quali sono le funzionalità di cui il processo ha bisogno per essere eseguito. A tempo di esecuzione, il gestore del processo cooperativo, assumendo il ruolo di Service Requestor, ricercherà presso il Service Broker il Web Service più opportuno per l implementazione del task corrente individuando anche le modalità di interazione con esso. Effettuato il passo di find, in base ad esempio a criteri di qualità, si passerà alla fase di bind con il conseguente scambio di dati, che consentirà l avanzamento nell esecuzione del processo cooperativo. Ogni scambio di messaggi avviene utilizzando un mezzo di trasporto comune. Essendo quindi l infrastruttura di comunicazione un parametro dell'architettura, si definisce [rif.16] una architettura per Web-Service, un istanza di una SOA in cui il mezzo di comunicazione considerato è il Web Nel recente periodo, diverse sono state le iniziative da parte dei maggiori vendor IT per realizzare un infrastruttura tecnologica per la creazione, invocazione e composizione di Web Service. Le soluzioni proposte possono ricondursi a quattro classi di obiettivi che rispecchiano altrettante problematiche legate alla tecnologia dei Web Service: linguaggi di descrizione delle interfacce e del comportamento di un servizio rivolto sia a chi realizza e pubblica il servizio, sia a chi lo cerca e utilizza; componenti per la memorizzazione e il reperimento di servizi, interrogabili secondo diversi criteri; 23

linguaggi di specifica per la conversazione tra diversi servizi; linguaggi di specifica di composizione di servizi a valore aggiunto partendo da servizi di base. Gli obiettivi fondamentali nelle scelte delle tecnologie impiegate per sviluppare WS sono l interoperabilità, la neutralità e la leggerezza. Ciò che assicura queste proprietà e che le distingue dalle precedenti tecnologie sono l impiego di XML e del protocollo SOAP (Service Oriented Access Protocol), che col tempo sono diventate anche degli standard, in quanto universalmente accettate da tutte le principali compagnie di software del mondo come mezzi più idonei per raggiungere gli obiettivi prefissati dal CIS. Di conseguenza le scelte tecnologiche sono ricadute su XML per strutturare i messaggi, SOAP per trasferirli, WSDL per descrivere le interfacce statiche dei WS, WSTL per descriverne il comportamento, cioè le possibili conversazioni in cui un WS è coinvolto, ed infine UDDI per rendere i WS accessibili attraverso un repository. 24

1.5.1 Web Service Description Language WSDL è un linguaggio nato per descrivere le capacità di un Web Service, in particolare la sua interfaccia statica : proposto da IBM e Microsoft, mette insieme le caratteristiche migliori del Network Accessibile Services Language (NASSL) di IBM e il SOAP Contract Language di Microsoft. Il linguaggio è basato su XML ed è parte integrante del progetto UDDI che descriveremo in seguito. Le specifiche della versione 1.1 [rif.17] lo definiscono come grammatica XML per descrivere servizi di rete come collezione di endpoint capaci di scambiarsi messaggi :come ci si aspetterebbe da uno standard, WSDL separa la definizione astratta degli endpoint dalla loro implementazione completa. La definizione di un servizio si basa su sette elementi fondamentali: Types, un contenitore per la definizione dei tipi di dato, in particolare dati strutturati (riconducibili all interno dei diagrammi UML ai <<type>> class); Message, la definizione astratta e tipizzata dei dati scambiati come parametri dei messaggi stessi (riconducibili all interno dei diagrammi UML ai <<message>> class); Operation, una descrizione astratta delle azioni supportate dal servizio; in particolare è possibile descrivere quattro tipologie di operazioni identificabili dal tipo di messaggi scambiati; Port Type, un insieme astratto di operazioni supportato da uno o più endpoint; Binding, il protocollo concreto utilizzato per la comunicazione e la specifica del formato dei dati di un particolare Port Type; Port, un singolo endpoint definito dalla combinazione di un indirizzo di rete (URL location) e di un indirizzo per il binding (SOAP binding); Service, una collezione di endpoint correlati tra loro, cioè interoperanti (riconducibili all interno dei diagrammi UML ai <<Web Service>> class). 25

Tale linguaggio permette di distinguere tre tipi di operazioni [rif.6] : Request/Response: operazione con messaggio in input ed output (entrambi non vuoti) e la cui richiesta è bloccante per il client; One Way: operazione con il solo messaggio in input (non vuoto) e quindi non bloccante per il client Notification: operazione con il solo messaggio in output (non vuoto), quale risultato di un operazione interna del WS. Message e Port Type forniscono una definizione astratta dei dati che saranno scambiati dal servizio e delle operazioni che questo è in grado di compiere su di essi: da questo punto di vista WSDL può essere assimilato all Interface Definition Language (IDL) di CORBA, anch esso specializzato nella descrizione delle interfacce di programmazione. Proprio questa analogia, o forse qualcosa di più dal momento che esistono tool automatici per la traduzione dell IDL in WSDL, ci permette di riflettere sul fatto che WSDL manca di costrutti in grado di descrivere gli aspetti comportamentali di un Web Service, ossia ad esempio in che ordine accetta gli input e in quale fornisce gli output, aspetto che lo stesso IDL non risolve. Perché la descrizione di un Web Service sia più completa, è necessario che venga descritta la sequenza corretta dello scambio di messaggi che il servizio è in grado di supportare. Per tale proposito si rimanda al paragrafo successivo in cui si darà la specifica del WSTL, linguaggio con il quale si propone di colmare tale lacuna. Riportiamo nella figura 1-3 la struttura di WSDL. 26

HTTP Client Mail Client Service Port (HTTP) Port (SMTP) Port Type HTTP SMTP 1..N 1 Binding Operation 1..2 Message SOAP SMTP 1 Type HTTP. Figura 1-3 - Struttura WSDL 1.5.2 Web Service Transition Language Come detto in precedenza il WSDL non risolve il problema di come un servizio possa specificare, per lo scambio di messaggi, le sequenze valide supportate; il WSTL si propone come una soluzione per la definizione, attraverso schemi XML, di tali sequenze valide (con il termine sequenza valida si intende una sequenza di transizioni, testualmente legal, legali, basate sullo scambio di messaggi). WSTL [rif.6] è il merge di altri due linguaggi proposti per raggiungere lo stesso scopo. Il primo, WSCL, adotta un approccio ereditato dal dominio degli agenti software, basato su protocolli di interazione intesi come conversation policy, e lo estende scegliendo XML come contenuto dei messaggi scambiati. Ogni specifica WSCL descrive un solo tipo di conversation dal punto di vista di uno solo dei due partecipanti, cioè quello per cui si sta scrivendo la specifica, dal momento che il 27

punto di vista dell altro interlocutore è facilmente deducibile. Il secondo, XLANG, si propone di individuare e specificare, anch esso tramite un documento XML, le caratteristiche di conversazione di un servizio. In realtà il proposito di XLANG era maggiormente ambizioso e puntava a gettare le basi per poter definire aspetti di composizione di servizi trascurati da WSCL. In seguito alla comparsa di altri linguaggi per la definizione di conversation tra Web Service, WSTL ha mire meno ambiziose ed in realtà è un semplice linguaggio capace di rappresentare la macchina a stati finiti associata ad un WS, in un linguaggio XML-based. In dettaglio un documento WSTL è costituito dai seguenti elementi: Una conversation: equivalente dell ASF( automa a stati finiti), consiste in una o più transizioni; Transition: rappresenta una singola transizione caratterizzata da uno stato sorgente, uno stato destinazione; ogni singola transizione può essere di tipo sincrono o asincrono; Input message: rappresentano il messaggio in input ad una transizione; Output message: rappresentano il messaggio in output ad una transizione. Gli stati sono codificati con dei numeri ed i messaggi sono quelli definiti all interno del documento WSDL relativo al WS d interesse (vedi esempio seguente). Prendendo l esempio il servizio del Rilascio del Porto d Armi, nelle seguenti tabelle si intende dare la sua definizione attraverso l interfaccia statica in WSDL e il comportamento in WSTL. <?xml version="1.0"?> -<definitions name="rilascioportoarmi" targetnamespace="http://agenzia21.org/rilascioportoarmi" xmlns:tns="http://agenzia21.org/rilascioportoarmi" xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/" xmlns="http://schemas.xmlsoap.org/wsdl/"> - <types> - <schema attributeformdefault="qualified" elementformdefault="qualified" targetnamespace="http://agenzia21.org/rilascioportoarmi" xmlns="http://www.w3.org/2001/xmlschema"> - <element name="rilascioportoarmirequest"> - <complextype> - <sequence> <element name="nome" type="string" /> <element name="cognome" type="string" /> <element name="datadinascita_ggmmaaaa" type="int" /> <element name="codicefiscale" type="string" /> <element name="statocivile" type="string" /> <element name="figli" type="boolean" /> - <element name="residenza"> - <complextype> - <sequence> <element name="via" type="string" /> <element name="numerocivico" type="int" /> 28