architettureinformatiche...

M O N D O D I G I T A L E • n . 1 - m a r z o 2 0 0 8

1. INTRODUZIONE

I l crescente sviluppo delle reti di telecomu-nicazioni e delle applicazioni informatiche

di rete ha portato l’industria IT a confrontarsicon nuove possibilità e nuove sfide. Da un la-to la grande diffusione della rete ha permessolo sviluppo di applicazioni distribuite basatesu protocolli “aperti” per fornire servizi agliutenti (si pensi ai portali web per avere unesempio significativo), dall’altro è aumentatala complessità delle applicazioni e la neces-sità di integrare sistemi informativi e piat-taforme eterogenee. In particolare, le aziendein un mercato globalizzato sentono semprepiù spesso la necessità di rendere accessibili iloro servizi globalmente. Questa esigenzacomporta la necessità di avere qualcosa in piùdi un front-end di rete (il portale web) visto co-me l’interfaccia di rete del sistema informati-co aziendale. Se un’azienda vuole essere unattore attivo del mercato globale, deve neces-sariamente integrarsi con l’esterno, con le ap-plicazioni di partner, fornitori e clienti. Il pro-blema di come integrare in modo efficace ser-vizi e applicazioni eterogenee non è solo un

problema di natura tecnologica, ma necessitadi un approccio interdisciplinare accompa-gnato da una forte azione di formazione dinuove competenze. Nel contesto di questo ar-ticolo non intediamo affrontare le problemati-che legislative, gli aspetti di organizzazioneaziendali (modelli di business innovativo, lastrutturazione dei processi ecc.), di formazio-ne, messe in essere dalla globalizzazione del-l’economia. Il nostro punto di vista sarà pret-tamente scientifico e tecnologico. In partico-lare, intendiamo evidenziare i limiti e le poten-zialità delle soluzioni informatiche basate sul-la nozione di servizio.Le Service Oriented Architecture (SOA) [9, 14]sono state introdotte per affrontare le sfidedelineate in precedenza. Il paradigma SOAsuggerisce una metodologia di progettazio-ne in cui applicazioni complesse sono realiz-zate attraverso l’interazione di entità chia-mate servizi. I servizi sono componenti com-putazionali autonomi, indipendenti dallapiattaforma, che possono essere descritti,pubblicati, individuati, composti ottenendoreti di applicazioni distribuite in grado di

Le architetture a servizi costituiscono il paradigma emergente per la pro-

gettazione e implementazione di applicazioni di rete. I servizi sono stru-

menti indipendenti dalla piattaforma, che possono essere descritti, pubbli-

cati e composti ottenendo reti di applicazioni distribuite. Questo lavoro si

propone di analizzare sia le sfide tecnologiche poste a chi progetta appli-

cazioni distribuite con il paradigma orientato ai servizi, che il problema della

definizione di nuovi modelli computazionali che favoriscono la realizzazio-

ne di strumenti software innovativi superando i limiti delle soluzioni tecnolo-

giche oggi disponibili.

Massimo BartolettiVincenzo CianciaGian Luigi FerrariRoberto GuancialeDaniele StrolloRoberto Zunino

ARCHITETTURE INFORMATICHEL’ORIENTAMENTO AI SERVIZI

19

3.4

0

operare all’interno di una singola organizza-zione e attraversarne i confini. L’applicazionecosì ottenuta diviene a sua volta un nuovoservizio disponibile sulla rete. È importantenotare che:� fornitori non vendono più software da in-stallare su sistemi proprietari del cliente, maforniscono un servizio;� l’integrazione di più servizi è trasparente alcliente, che vede la collaborazione di più ap-plicazioni come un unico servizio. Questopermette sia al cliente che al fornitore di po-ter cambiare i loro rispettivi fornitori, indi-pendentemente da come questi abbiano svi-luppato le loro funzionalità.Nell’ambito di un’architettura SOA è quindipossibile modificare, in maniera relativamen-te semplice, le modalità di interazione tra iservizi, oppure la combinazione nella quale iservizi vengono utilizzati all’interno di un pro-cesso di business. Allo stesso modo risultapiù agevole aggiungere nuovi servizi e modi-ficare le soluzioni software per rispondere al-le specifiche esigenze di business. In altri ter-mini, il processo di business specifico di un’a-zienda non è più vincolato da una particolarepiattaforma o da un’applicazione ma può es-sere considerato come un componente di unprocesso più ampio e quindi può essere riuti-lizzato o modificato. Concettualmente, il pa-radigma SOA può essere descritto come il pa-radigma computazionale in cui i servizi inte-roperano mediante un meccanismo di descri-zione autonomo, il contratto del servizio, in-dipendente dalla piattaforma sottostante edalle tecnologie di sviluppo. Pertanto, i servi-zi in esecuzione su una piattaforma possonoanche utilizzare servizi in esecuzione su altrefacilitando quindi la riusabilità.I servizi web (web services), sono probabil-mente la tecnologia maggiormente sviluppa-ta per la progettazione e realizzazione di ap-plicazioni SOA. In letteratura, esistono defini-zioni differenti di cosa sia un servizio web. Lanozione di servizio web definita dal World Wi-de Web Consortium (W3C) evidenzia bene gliaspetti caratterizzanti dei servizi web. “A Webservice is a software system designed to sup-port interoperable machine-to-machine inte-raction over a network. It has an interface de-scribed in a machine-processable format(specifically WSDL). Other systems interact

with the Web service in a manner prescribedby its description using SOAP-messages, typi-cally conveyed using HTTP with an XML seria-lization in conjunction with other Web-relatedstandards” (cfr http://www.w3.org/TR/ws-gloss/).La definizione riportata in precedenza eviden-zia bene le caratteristiche essenziali di un pa-radigma computazionale basato sui serviziweb. Le operazioni dei servizi (descrizione,pubblicazione, ricerca e l’invocazione) sonobasate sullo scambio di messaggi codificati inXML. XMLè uno standard di rappresentazionedei dati indipendente dalle diverse piattafor-me applicative. Il protocollo SOAP (SimpleObject Access Protocol) definisce i meccani-smi di interazione tra servizi. WSDL (Web Ser-vice Description Language) è il linguaggio didescrizione delle operazioni del servizio e del-le sue modalità di interazione. Infine, i serviziweb utilizzano i protocolli standard di internetquali HTTP (Hyper Text Transfer Protocol),SMTP (Simple Mail Transfer Protocol), e MIME(Multipurpose Internet Mail Extension). Unavolta definiti e resi disponibili i servizi si avver-te la necessità di disporre di un registro deiservizi disponibili e di un protocollo di ricercadei servizi all’interno della propria rete. Il pro-tocollo UDDI (Universal Description, Disco-very and Integration) è la risposta standard aquesta esigenza. Per una presentazione det-tagliata della struttura e delle caratteristichedei servizi web e per un’introduzione agile eragionata alle problematiche dei servizi si ri-manda alla bibliografia [1, 15].Uno degli aspetti innovativi delle architettureSOA e dei servizi web in particolare riguardala composizione e il coordinamento dei servi-zi. La definizione delle politiche di coordina-mento dei servizi avviene attualmente in ma-niera pragmatica, risolvendo gli aspetti cru-ciali del coordinamento caso per caso. Inquesto modo, si garantisce l’interoperabilitàdella soluzione ma alcune proprietà signifi-cative come il rispetto dei vincoli di sicurezzao l’utilizzo efficiente delle risorse non sononecessariamente assicurate. A seconda delmodello utilizzato per realizzare le politichedi coordinamento si parla di orchestrazioneo di coreografia. La differenza sostanziale traqueste due modelli di coordinazione consi-ste nella visione che i servizi hanno l’uno del-


1

0

0

1

20

l’altro. Nell’orchestrazione l’attenzione è in-centrata su ogni singolo partecipante men-tre, nella coreografia, ad ogni partecipante èofferta una visione parziale o addirittura glo-bale del sistema. La babele di proposte distandard per orchestrazione e coreografia diservizi sviluppati negli ultimi anni (WSCI,BPML, WSFL, BPEL4WS, BTP, WS-CDL) testi-monia la necessità di linguaggi per il coordi-namento dei servizi. Rimanendo sul versantetecnologico, la Service Component Architec-ture (SCA) [8] è molto probabilmente l’esem-pio maggiormente significativo di modello diprogrammazione per servizi che pone unaparticolare enfasi sugli aspetti di definizionee realizzazione delle politiche di coordina-mento dei servizi nel progetto di soluzionibusiness (gli assembly dei servizi nella termi-nologia SCA).Realizzare politiche di coordinamento deiservizio non è solamente un problema tec-nologico. Nella letteratura scientifica sonopresenti diverse proposte di natura fonda-zionale che cercano di risolvere alcuniaspetti essenziali del problema. Altrettantoforte è l’interesse del mondo accademico edella ricerca di base alle problematiche rela-tive alla definizione di linguaggi per il coor-dinamento dei servizi [13, 14, 20]. Le diverseproposte forniscono strumenti matematiciper esprimere e certificare in modo formaleproprietà generali sul comportamento dipolitiche di coordinamento di servizi. Unesempio significativo di politica di coordina-mento riguarda le “transazioni di lunga du-rata” (long running transactions). Le transa-zioni di lunga durata sono un meccanismofondamentale per aumentare la robustezzadelle applicazioni di business realizzate tra-mite servizi. Le transazioni long runningperdono la proprietà di serializzabilità epossiedono una nozione meno restrittiva diatomicità garantita da rollback ad-hoc chia-mati “compensazioni” [11]. Un altro aspettoimportante riguarda la definizione di politi-che di sicurezza. I meccanismi forniti daglistandard di WS-security non sono sufficien-ti a garantire la sicurezza di una soluzionebusiness, anche nel caso in cui i protocolliadoperati siano sicuri. La sicurezza di un si-stema progettato con un’architettura a ser-vizi può essere violata a causa di comporta-

menti inattesi e indesiderati che si rilevanosolamente coordinando i servizi.La definizione di modelli formali di certifica-zione di proprietà di politiche di coordina-mento per architetture a servizi è essenzialeper comprendere e garantire che una speci-fica soluzione di business soddisfi i requisi-ti richiesti e, in caso contrario, per compren-dere quando e perchè si è verificato un pro-blema. Più in generale la capacità di analiz-zare e certificare proprietà delle politiche dicoordinamento dei servizi consente di pro-gettare soluzioni software robuste in gradodi prevedere ed evitare i problemi prima chesi verifichino. Chi progetta un sistema dinorma conosce un servizio solamente tra-mite le informazioni presenti nella descri-zione WSDL del servizio stesso. È difficilecomprendere quale servizio ha causato unproblema e perchè. La definizione di mecca-nismi di certificazione delle proprietà dicoordinamento costituisce, a nostro parere,il valore aggiunto delle soluzioni SOA basa-te su servizi web.Questo articolo si pone l’obiettivo di presen-tare e analizzare alcune delle problematichetecnologiche e scientifiche poste dalla ne-cessità di definire compiutamente politicheper il cordinamento di servizi. Il primo aspet-to che prenderemo in esame in questo no-stro percorso riguarda le problematiche re-lative alla progettazione di servizi con tran-sazioni long-running. La parte finale dell’ar-ticolo sarà dedicata alla presentazione diuna metodologia che si propone di aiutare ildesigner nella fase di progettazione degli or-chestratori di servizi in modo tale che l’ap-plicazione nella sua interezza rispetti tutti icontratti di sicurezza posti in essere. Il no-stro obiettivo è quello di illustrare l’idea(provocatoria) che la sinergia tra lo sviluppotecnologico e la ricerca di base possa favori-re la progettazione e lo sviluppo di soluzioniinnovative per le aziende che operano nelmercato globale. In particolare, intendiamomostrare come l’introduzione di metodolo-gie basate su tecniche e strumenti di certifi-cazione di proprietà favorisca la realizzazio-ne di nuovi strumenti software a valore ag-giunto in una prospettiva di internetworkedenterprise superando i limiti delle soluzionisoftware oggi disponibili.


1

21

0

0

0

1

0

2. LE POLITICHEDI COORDINAMENTODEI SERVIZI

La programmazione di applicazioni SOA ri-chiede di affrontare nuove problematiche[18, 19]. La composizione di servizi e la de-scrizione del loro flusso di esecuzione nonpuò essere arbitraria. Le politiche che regola-no l’esecuzione di servizi sono spesso indi-cate con il termine generico di politiche dicoordinazione. A seconda del modello utiliz-zato per implementare la coordinazione, siparla di orchestrazione o di coreografia. Ladifferenza sostanziale tra i due modelli consi-ste nella visione che i servizi hanno l’uno del-l’altro. Nell’orchestrazione l’attenzione è in-centrata su ogni singolo partecipante men-tre, nella coreografia, ad ogni partecipante èofferta una visione parziale o addirittura glo-bale del sistema. Nel seguito verranno me-glio evidenziate queste differenze cercandodi enfatizzare quelli che sono i punti di forzae gli svantaggi dei due modelli.Il termine orchestrazione si rifà alla metaforadi un’orchestra in cui i singoli musicisti hannoconoscenza della propria attività da svolgeree attendono dal direttore di orchestra (orche-strator) le direttive prima di eseguire la pros-sima attività. Il maggiore svantaggio che que-sto modello comporta riguarda la centralizza-zione del punto di controllo da parte dell’or-chestratore. Seppure esistano soluzioni cheprevedono la distribuzione del flusso di con-trollo tra diversi orchestratori resta di fattoche le informazioni di controllo siano gestitesolamente da orchestratori. Il vantaggio chene deriva da questo modello riguarda il totaleisolamento dei servizi stessi, i quali non san-no in quale flusso di lavoro sono coinvolti e silimitano a svolgere le proprie attività compor-tandosi sempre allo stesso modo indipen-dentemente dal contesto di esecuzione.Il linguaggio per la specifica di orchestrazio-ne di servizi web più diffuso attualmente, ri-sulta essere il Business Process ExecutionLanguage (BPEL) [6,12]. BPEL definisce deicostrutti ad alto livello (ad esempio condi-zionale, cicli, join di flussi paralleli) che ven-gono utilizzati dall’orchestratore per con-trollo di flusso. BPEL è un linguaggio ese-guibile in quanto, una volta date le specifi-che del workflow all’engine di orchestrazio-

ne, questo si occupa di eseguire le opportu-ne attività.Nella metafora della coreografia, ogni parteci-pante, in funzione delle azioni intraprese daglialtri partecipanti (non necessariamente datutti) decide quale sia l’operazione da intra-prendere. Di solito questo paradigma di coor-dinamento viene descritto dalla metafora deiballerini “Dancers dance following a globalscenario without a single point of control”. Ilmaggior vantaggio di questa strategia risiedenella totale distribuzione delle informazioni diworkflow ai componenti. Tuttavia, si deve evi-denziare il fatto che i servizi coinvolti in unacoreografia sono ben consapevoli del conte-sto in cui si trovano ad agire e, pertanto, risul-tano meno isolati rispetto a servizi utilizzatinell’orchestrazione. I servizi devono essereprogettati preventivando di essere utilizzatiall’interno di coreografia per cui devonoesportare alcune funzionalità di supporto perpoter gestire lo stato del flusso. Solitamentetalune strategie che implementano coreogra-fia, impongono l’utilizzo di servizi con stato(servizi statefull) al fine di mantenere consi-stenti i dati relativi alla gestione del flusso.Uno standard per la descrizione di coreografieè WS-CDL (Web Service Choreography De-scription Language) [16]. La specifica WS-CDLprevede la stipula un contratto che contiene ladefinizione globale di vincoli necessari a ga-rantire il normale svolgimento di tutte le atti-vità. Questa visione globale viene successiva-mente proiettata nei singoli partner i quali de-vono garantire di assumere un comportamen-to conforme con quanto loro richiesto.

3. LA CERTIFICAZIONEDEI SERVIZI

I linguaggi attualmente usati per descrivere leoperazioni che i servizi web offrono agli utentisono basati su XML e, pertanto, puramentesintattici, cioè non specificano alcuna pro-prietà comportamentale associata all’invoca-zione del servizio. Tipicamente è la documen-tazione semi-formale del servizio a spiegarequali sono gli effetti che ci si aspetta quandosi utilizza una determinata funzionalità.Il problema di superare i vincoli sintattici dellasuite dei protocolli dei servizi web è stato af-frontato facendo ricorso a metodi differenti.


1

0

0

1

22

Una delle soluzioni presenti in letteratura èquella del Semantic Web [7]. L’idea di base diquesta soluzione consiste nel formalizzare re-lazioni fra simboli (le ontologie) in modo daguidare l’attività di ricerca di un servizio. Se sidescrive tramite una ontologia che “regione”è allo stesso tempo un sottoinsieme di “stato”e un sovrainsieme di “città”, un cliente checerca servizi web legati ad aziende della Lom-bardia può avere come risposta non soloquelli che identificano esattamente, la regio-ne, ma anche altri che coprono quella più am-pia dell’Italia, o quella più ristretta di Milano.Sono in fase di sviluppo alcuni standard perspecificare ontologie e servizi. Tra queste pro-poste citiamo WSML (Web Service ModelingLanguage), OWL (Ontology Web Language),WSMO (Web Service Modeling Ontology).Una differente linea di ricerca affronta questoproblema mediante l’uso di metodi formali perlacertificazioneeverificadiproprietà [20].Quan-do si parla di verifica di componenti software,ci si riferisce all’uso di un meccanismo che con-senta di dimostrare matematicamente l’ade-renza del componente a un insieme di requisi-ti, tipicamente espressi usando un linguaggioformale, derivato dalla logica matematica. Nelcontesto di questo lavoro considereremo le tec-niche di verifica di model-checking. Le tecnichedi model-checking permettono di verificare pro-prietà di un modello, sia esso specificato a tem-po di progettazione, oppure estrapolato dal co-dice stesso del programma dopo la fase di im-plementazione.Gli strumenti automatici cheso-no in grado di eseguire il processo di verifica so-no chiamati model-checker. Se applicato a mo-delli creati durante la fase di progettazione, ilmodel-checking consente di evitare di propa-gare eventuali errori alle fasi successive dellosviluppo, a differenza di testing che invece ope-ra sul prodotto finito. Inoltre, il model checkingha un ruolo importante anche all’interno di unametodologia agile, dato che è possibile inte-grare il testing con esecuzioni dello strumentodi verifica, esegnalare immediatamenteallosvi-luppatore eventuali problemi non catturati daicasi di test. Una delle caratteristiche che ren-dono interessante l’usodelmodel-checkingnel-la progettazione software è che, nel caso in cuiun requisito venga violato, il model-checker re-stituisce un percorso di esecuzione che rap-presenta tutti gli stati attraversati dal sistema

fino al fallimento. Questo rende più facile evi-tare gli errori di progettazione, che influenzanoa volte in maniera determinante l’implementa-zione, e se scoperti troppo tardi possono co-stringere a costosi re-factoring.Le tecniche di model-checking si applicano inmodo naturale a problemi in cui ciò che contanon è quali dati passino nel sistema, ma piut-tosto il flusso di controllo, o il flusso dei da-ti. Per estrapolare il flusso di controllo o deidati di un programma o di un progettosoftware, si possono usare tecniche raffinatecome l’astrazione, che consiste in una esecu-zione “simbolica” del programma stesso, chegenera via via un modello non completo, masufficiente a fare una verifica di molte pro-prietà interessanti. Un esempio significativoè fornito da Java PathFinder. Java PathFinderè un ambiente di sviluppo per programmi Ja-va sviluppato dalla NASA in cui sono disponi-bili un meccanismo di astrazione e un model-checking che analizza bytecode Java. JavaPathFinder consente di verificare automati-camente proprietà di assenza di deadlock etrovare eccezioni non gestite, generando unatraccia dell’esecuzione del software che por-ta alla condizione di errore.Storicamente, il model-checking è stato pro-posto in seguito ai lavoro pionieristici di E. M.Clarke, E. A. Emerson nel 1981, e di J. P. Queille,J. Sifakis nel 1982. Clarke, Emerson e Sifakissono stati recentemente insigniti del TuringAward per il 2008 per i risultati ottenuti nelcampo del model-checking. Il Turing Award è ilprincipale riconoscimento scientifico assegna-to a ricercatori per il loro contribuito allo svi-luppo dell’informatica. Nella direzione del mo-del-checking si stanno muovendo anche legrandi imprese fornitrici di software e servizi.

4. LE TRANSAZIONI DI LUNGADURATA

Un aspetto importante e innovativo delle po-litiche di coordinamento dei servizi riguardagli aspetti transazionali. Spesso l’esecuzionedi una politica di coordinamento richiede nu-merose interazioni con l’utente o con proces-si intermedi che vanno anche al di fuori del-l’applicazione. Si pensi per esempio ad unservizio di vendita online che accetta paga-menti tramite servizi che effettuano bonifico


1

23

0

0

0

1

0

bancario. In questa situazione, il pagamentopotrebbe essere notificato alcuni giorni dopoche l’attività di prenotazione dell’acquistodel bene ha iniziato il suo ciclo. Per questimotivi, le tecniche tradizionali dei sistemi di-stribuiti non sono sufficienti a garantire lacorrettezza di comportamenti transazionali.Infatti non è possibile riutilizzare le tecnichetradizionale per la gestione dellle transazioni(transazioni ACID) dato che i tempi di esecu-zione delle operazioni coinvolte sono moltolunghi ed è impensabile attuare meccanismitradizionali di locking, rollback e isolamento.LeTransazioni LongRunning, transazioni di lun-ga durata, sono lo strumento principale che èstato adottato per rispondere alle richieste diatomicità di servizi. Il meccanismo computa-zionaleadottatoperoperareagilmentecon tran-sazioni di lunga durata è la compensazione(compensation). La nozione di compensazioneè stata introdotta nei processi SAGAS [11]. Lecompensazioni sono quelle attività che per-mettono di programmare quelle azioni da ese-guire per rispristinare lo stato dell’esecuzioneparziale di un processo di business. Intuitiva-mente, le compensazioni possono essere vistecome un meccanismo di gestione delle ecce-zioni programmabile. Si consideri, per esem-pio, il seguente processo transazionale:

P := [A1 << B1] ; [A2 << B2] ; [A3<< B3]

Il processo transazionale P è costituito dallacomposizione sequenziale di tre attività (A1,A2 e A3). Ad ogni attività è associata unacompensazione specifica. Per comprendere ilcomportamento del processo, supponiamoche l’attività A1 completi con successo la pro-

pria esecuzione, mentre l’esecuzione dell’at-tività A2 generi una situazione di fallimento.In seguito alla segnalazione del fallimento diA2, viene mandato in esecuzione la compen-sazione B1 (quella associata all’attività A1terminata con successo) per ripristinare lostato dell’esecuzione del processo. In altritermini, il fallimento dell’attività ha compor-tato il fallimento dell’intero processo transa-zionale. Si noti che la compensazione B2 nondeve essere mandata in esecuzione dato cheA2 non ha completato la propria esecuzionecon successo. Similmente, nel caso in cui A1e A2 abbiano completato con successo l’ese-cuzione il processo transazionale terminacon succcesso solamente nel caso in cui A3abbia successo. In caso di fallimento di A3saranno mandate in esecuzione le compen-sazioni B2 e B3. Infine, le compensazioni B3,B2 e B1 saranno eseguite in quest’ordine nelcaso in cui P sia un sottoprocesso di un pro-cesso transazionale e che P abbia ricevutouna notifica di fallimento dopo aver conclusocon successo la propria esecuzione.Questo semplice esempio bene evidenzia l’i-dea che le compensazioni sono quelle azioniche devono essere eseguite localmente perripristinare la consistenza dello stato localedel servizio nel caso di notifica di fallimento.Il diagramma illustrato nella figura 1 descrivela specifica ad alto livello della componentetransazionale di un servizio che ha il compitodi modificare in parallelo lo stato di un certonumero di oggetti distinti tra loro. Si supponeche gli oggetti siano accessibili dal servizio eche siano memorizzati in un sistema legacyche garantisce il roll-back perfetto tramite leazioni standard di Commit e Rollback.


1

0

0

1

24

FIGURA 1Transazioni di lunga

durata in Sagas

<<UnlockObjN

UnlockObj1LockObj1

<<UnlockObj1

UploadObj1

<<D elObj1

Commit

<<R ollback

LockObjN

<<UnlockObjN

UploadObjN

<<D elObjN

La maggior parte dei modelli di workflow pre-senti in letteratura adotta l’idea di compen-sazione per la corretta gestione delle transa-zioni di lunga durata. Le diverse proposte dif-feriscono tra loro per la presenza di compen-sazioni aventi caratteristiche differenti (peresempio compensazioni gerarchiche). Si ri-manda alla nota [17] per un’analisi dettaglia-ta delle diverse proposte.Per comprendere come affrontare il proble-ma della progettazione transazioni longrunning, consideriamo un caso di studiopiccolo ma significativo. Consideriamo il ca-so di un veicolo equipaggiato con un siste-ma di diagnostica digitale. Il sistema con-trolla periodicamento lo stato dell’automo-bile, e quando si presentano situazioni diguasto (surriscaldamento del motore, liqui-di sotto livello di soglia ecc.) il sistema atti-va automaticamente un servizio di emer-genza. Il servizio di emergenza medianteuna interazione con l’utente determina eseleziona il servizio necessario per la ge-stione della situazione di emergenza. Persemplicità, supponiamo che il sistema diemergenza possa selezionare e richiedereun servizio di carro–attrezzi e un servizio diofficina per la riparazione del quasto rileva-to. Supponiamo, inoltre, che possa venire

richiesto opzionalmente un servizio di mac-china a noleggio.La figura 2 illustra il design del workflow delcaso di studio descritto in prccedenza. Larappresentazione grafica del workflow utiliz-za la notazione standard denominata BPMN(Business Process Modeling Notation). Permaggiori dettagli su BPMN si consiglia di fareriferimento al sito http://www.bpmn.org/.Nel workflow di figura 2, la sottotransazioneche gestisce l’operazione di noleggio dell’au-toveicolo è isolata dal resto del processo.Questo comporta che il fallimento della suaesecuzione non determina automaticamenteil fallimento del workflow nella sua interezza.

5. UNA METODOLOGIAPER L’ORCHESTRAZIONESICURA DI SERVIZI

La sicurezza dei sistemi software è una que-stione cruciale in un mondo sempre più per-meato dall’Information Technology. Anche leapplicazioni basate sui servizi web presenta-no forti requisiti di sicurezza visto che opera-no nel contesto distribuito e insicuro di Inter-net. Autorevoli enti, come il CERT della Car-negie Mellon University, riportano un nume-ro sempre crescente di segnalazioni relative


1

25

0

0

0

1

FIGURA 2Un processodi business concompensazionenella notazioneBPMN

RedirectRental Car

ChargeCredit Card

Order GarageAppointment

OrderTow Truck

RevokeCharge

Cancel GarageAppointment

CancelTow Truck

OrderRental Car

0

alla vulnerabilità dei sistemi informatici,spesso dovute a problemi nella progettazio-ne e realizzazione del software. La soluzionetipica è quella di riparare tali “falle” renden-done più difficile l’utilizzo da parte degli at-taccanti, ma questo approccio non va certa-mente alla radice del problema. Un approc-cio complementare è, invece, quello di mo-dellare e verificare i requisiti di sicurezza findalla specifica di un sistema software, al finedi ridurre al minimo le vulnerabilità sul pro-dotto finale. L’adozione di tecniche formalipuò quindi giocare un ruolo molto importan-te per individuare possibili problemi di sicu-rezza fin dalle prime fasi di progettazione percapirne a fondo le cause e per rimuoverli pri-ma che altre scelte progettuali costringano a

“inventare” rimedi a posteriori, non semprepossibili e soddisfacenti. I meccanismi fornitidagli standard di WS-security non sono suffi-cienti a garantire la sicurezza di una soluzio-ne business, anche nel caso che i protocolliadoperati siano sicuri. Il problema principaleè come orchestrare servizi, garantendo dinon abortire l’esecuzione dell’orchestrazio-ne a causa di azioni che tentano di violare lasicurezza. I servizi che soddisfano localmen-te la proprietà richiesta non sono semprebuoni candidati, dato che il loro comporta-mento può altresì invalidare la sicurezza del-l’intera orchestrazione.Per comprendere come affrontare il proble-ma della sicurezza, consideriamo una picco-la estensione del caso di studio presentatoin precedenza. In particolare assumiamoche la selezione di un servizio possa tenereconto delle preferenze del conducente delveicolo. Per semplicità, supponiamo che ilsistema di emergenza possa selezionare erichiedere un servizio di carro–attrezzi e unservizio di officina per la riparazione delguasto rilevato. Il nostro obiettivo è quellodi illustrare le principali caratteristiche diuna metodologia di supporto progettazionedella orchestrazione dei servizi. Per farequesto utilizzeremo una notazione grafica ala UML (diagrammi dell’attività, e diagram-mi dei casi di studio).La metodologia per la definizione dell’orche-strazione sicura dei servizi è stata definita in[2, 3, 4] e sfrutta una tecnica di model-checking che a partire dai contratto di servi-zio determina tutte le possibili orchestrazioniche soddisfano i contratti in opera. Tecnica-mente, i contratti di servizi sono una esten-sione dei documenti WSDL e sono formal-mente definiti mediante un’opportuno siste-ma di tipo.Per introdurre in modo semplice la notazio-ne, presentiamo il servizio di car-emer-gency, ovvero il servizio invocato dal siste-ma di diagnistica del veicolo per la gestionedelle situazioni di emergenza. Il diagrammanella figura 3 descrive la specifica del com-portamento del servizio di car-emergency. Ilservizio è definito mediante una forma par-ticolare di diagramma delle attività in cuisono descritti l’interfaccia del servizio (laparte superiore del diagramma) ed il flusso


1

0

0

1

26

FIGURA 3Car-emergency

service

del suo comportamento. Un aspetto impor-tante della metodologia è che devono esse-re definite anche le politiche che vincolanoil comportamento del servizio. In particola-re, la politica ϕBL indica che il servizio me-morizza, localmente, le officine che nonhanno soddisfatto l’utente. L’idea è che altermine della riparazione il servizio di offici-na deve firmare digitalmente un certificatodi qualità. Se l’utente non è soddisfatto del-la qualità del servizio offerto inserisce l’offi-cina nella lista nera (black list - BL) delle of-ficine. Le officine inserite nella black-listnon saranno più considerate per la gestionedi emergenze. La politica di qualità è defini-ta dall’automa a stati finiti nella parte infe-riore della figura. Analogamente al serviziodi emergenza, tutti i servizi presenti posso-no specificare la loro politica di qualità. Peresempio, il servizio di officina assume lapresenza di una politica di raggiungibilitàda parte del carro attrezzi. La poltica ϕGZcontrolla che il carro attrezzi sia effettiva-mente in grado di raggiungere l’officina.La parte innovativa del diagramma delle at-tività riguarda l’introduzione del blocco diorchestrazione, ovvero quella parte dellasequenza del flusso di esecuzione compre-sa tra le parentesi grafe. In questo caso, ilblocco permette di specificare la richiesta diorchestrare due chiamate di servizio, unaper il carro attrezzi e l’altra per l’officinia diriparazione. La caratteristica originale dellametodologia è che l’orchestrazione è defini-te mediante un meccanismo di chiamata deiservizi per contratto. La chiamata per con-tratto prevede che la selezione dei servizisia basata sulle proprietà di cui essi godo-no, piuttosto che sull’identità del produtto-re del servizio, come accade normalmente.Il blocco di orchestrazione ha il compito diindividuare una orchestrazione valida perentrambe l’invocazioni di servizio. Infattinon ha significato alcuno prenotare il carroattrezzi quando l’officina non è disponibile.L’orchestrazione viene individuata median-te l’invocazione di uno strumento di modelchecking che determina la lista delle orche-strazioni valide.La figura 4 descrive un diagramma di caso distudio (Use Case Diagram) in cui sono pre-senti un cliente e quattro servizi (due offici-

ne e due servizi di carro attrezzi). Ipotizzia-mo che l’automobile abbia una emergenzaai pneumatici nella zona di Pisa (ZIPPI) e chel’officina in Lucca sia stata inserita nella li-sta nera (sgnLU) in precedenza. Inoltre, unservizio di carro attrezzi opera nelle provin-cie di Pisa, e Firenze, mentre l’altro servizioopera nelle provincie di Pisa, Siena e Lucca.Infine, entrambe le officine offrono il servi-


1

27

0

0

0

1

FIGURA 4Diagramma casodi studio

0

zio di riparazione e sostituzione dei pneu-matici. Si può facilmente notare che l’orche-strazione che invoca il servizio di carro at-trezzi T2 e l’officina che opera a Lucca, violala politica definite dall’utente. L’orchestra-zione che invoca il servizio di carro attrezziT1 e il servizio di officina di Firenze rispettatutti i contratti posti in opera.La metodologia descritta in precedenza èsupportata da un middleware di programma-zione denominato JSCL (Java Signal CoreLayer) [10]. JSCL è equipaggiato con un am-biente di sviluppo grafico (tecnicamente unPlug-in di Eclipse) che permette di generareautomaticamente il codice della orchestra-zione a partire dalla descrizione del flussodelle attività. Infine, JSCL fornisce un suppor-to automatico alla progettazione ed imple-mentazione di transazioni long-running [5].

6. CONCLUSIONI

In questo lavoro abbiamo cercato di individua-re alcune delle sfide poste a chi progetta appli-cazioni distribuite con il paradigma orientatoai servizi. Il nostro obiettivo è stato quello di il-lustrare l’idea che la giusta miscela tra innova-zione tecnologica e ricerca fondazionale di ba-se favorisca la realizzazione di strumentisoftware innovativi superando i limiti delle so-luzioni tecnologiche oggi disponibili.Le problematiche descritte in questo arti-colo sono state affrontate in progetti di ri-cerca sia in ambito nazionale che europeo.In Italia è attualmente in corso il progettodi ricerca di base FIRB denominato TO-CAI.IT, Tecnologie Orientate alla Conoscen-za per Aggregazioni di Imprese in Internet(http://www.dis.uniroma1.it/~tocai/index.php). In particolare nel contesto di questoprogetto sono studiate e sperimentati iservizi di base forniti dal middleware JSCLper la progettazione di comportamentitransazionali per servizi. Nel contesto del6th – (FP6) è attivo il progetto SENSORIA,Software Engineering for Service-OrientedOverlay Computers (http://www.sensoria-ist.eu/) che si pone l’obiettivo di definireun insieme di metodologie innovative perla progettazione e sviluppo di architetturesoftware orientate ai servizi. La specifica el’implementazione di JSCL, la metodologia

per l’orchestrazione sicura di componentisono stati realizzati all’interno di questoprogetto.

Bibliografia

[1] Alonso G., Casati F., Kuno H., Machiraju V.: WebServices: Concepts, Architecture and Applica-tions. Springer Verlag 2004.

[2] Bartoletti M., Degano P., Ferrari G.: Types andEffects for Secure Service Orchestration. Proc.19th IEEE Computer Security Foundations Work-shop (CSFW’06), IEEE Press, 2006.

[3] Bartoletti M., Degano P., Ferrari G., Zunino R.:Secure Service Orchestration. Foundations ofSecurity Analysis and Design IV, FOSAD2006/2007 Tutorial Lectures, Lecture Notes inComputer Science 4677, Springer 2007.

[4] Bartoletti M., Degano P., Ferrari G., Zunino R.:Semantics-based design for Secure Web Servi-ces. IEEE Transactions on Software Enginee-ring, TSE, Vol. 34, n. 1, 2008.

[5] Bruni R., Ferrari G., Melgratti H., Montanari U.,Strollo D., Tuosto E.: From Theory to Practice inTransactional Composition of Web Services.Formal Techniques for Computer Systems andBusiness Processes, Lecture Notes in ComputerScience 3670, Springer 2005.

[6] Business Process Execution Language (BPEL).Disponibile on line all’indirizzo http://www-128.ibm.com/developerworks/library/specification/ws-bpel/

[7] Cardoso J., Sheth A.: Amit. Semantic Web Servi-ces, Processes and Applications. Springer 2006.

[8] Chappel D.: Introducing SCA. Disponibile on lineall’indirizzo (http://www.davidchappell.com/-articles/Introducing_SCA.pdf), July 2007.

[9] Erl T.: SOA Principles of Service Design. ThePrentice Hall Service-Oriented Computing Se-ries, Prentice Hall 2007

[10] Ferrari G., Guanciale R., Strollo D.: JSCL: A Midd-leware for Service Coordination. 26th IFIP WG6.1, Formal Techniques for Networked and Di-stributed Systems – FORTE 2006, Lecture Notesin Computer Science 4229, Springer 2007.

[11] Garcia-Molina H., Salem K.: Sagas. Internatio-nal Conference on Management of Data, ACMSIGMOD, ACM Press, 1987.

[12] Juric M., Mathew B., Sarang P.: Business Pro-cess Execution Language for Web Services.PACKT Publishing, 2006.

[13] Kitchin J., Cook W.R., Misra J.: A Language forTask Orchestration and Its Semantic Properties.CONCUR 2006, Lecture Notes in ComputerScience, 4137 Springer 2006.


1

0

0

1

28

[14] Papazoglou M., Georgakopoulos D.: Special is-sue on service oriented computing. Communi-cations of the ACM, Vol. 46, n. 10, 2003.

[15] Pernici B., Plebani P.: Introduzione ragionata almondo dei Web Service. Mondo Digitale, marzo2004, AICA.

[16] Ross-Talbot S., Fletcher T.: Web Services Cho-reography Description Language. Primer,W3C Working Draft, 2006(http://www.w3.org/TR/2006/WD-ws-cdl-10-primer-20060619/)

[17] Sheth A., Worah D.: Transactions in Transac-tional Workflows. Advanded Transaction Mo-

dels and Architectures, Kluwer, 1997.

[18] Stal M.: Web services: Beyond component-ba-sed computing. Communications of the ACM,Vol. 55, n. 10, 2002.

[19] Vogels W.: Web services are not distributedobjects. IEEE Internet Computing, Vol. 7,n. 6, 2003.

[20] Wirsing M., et~al: Semantic-based develop-ment of service-oriented systems. 26th IFIPWG 6.1, Formal Techniques for Networkedand Distributed Systems – FORTE 2006, Lec-ture Notes in Computer Science 4229, Sprin-ger 2007.


1

29

0

0

0

1

MASSIMO BARTOLETTI ha ottenuto il Dottorato di Ricerca in Informatica, Scuola Galilei, Università d Pisa. Titolaredi un assegno di ricerca presso il Dipartimento di Informatica Università di Pisa. I suoi interessi riguardano leproblematiche relative alla specifica e verifica di proprietà di sicurezza in sistemi distribuiti.E-mail: [email protected]

VINCENZA CIANCIA sta terminando il Dottorato di Ricerca in Informatica, Scuola Galilei, Università di Pisa. I suoiinteressi riguardano l'utilizzo di metodi formali nella certificazione di programmi.E-mail: [email protected]

GIAN LUIGI FERRARI professore associato presso il Dipartimento di Informatica Università di Pisa. I suoi inte-ressi più recenti riguardano i metodi e gli strumenti per la progettazione e la realizzazione di architetturesoftware orientate ai servizi. È autore di molte pubblicazioni internazionali, tra cui oltre cento articoli su ri-viste e atti di convegni.E-mail: [email protected]

ROBERTO GUANCIALE sta terminando il Dottorato di Ricerca in Scienze e Tecnologie dell'Informatica, Institutes forAdvances Studies, IMT, Lucca. I suoi interessi riguardano il progetto e la realizzazione di architetture softwareorientate ai servizi.E-mail: [email protected].

DANIELE STROLLO sta terminando il Dottorato di Ricerca in Scienze e Tecnologie dell'Informatica, Institutes forAdvances Studies, IMT, Lucca. I suoi interessi riguardano il progetto e la realizzazione di architetture softwareorientate ai servizi.E-mail: [email protected].

ROBERTO ZUNINO Ricercatore Universitario presso il Dipartimento di Informatica e Telecomunicazioni, Universitàdi Trento. I suoi interessi riguardano le problematiche relative alla specifica e verifica di proprietà di sicurezzain sistemi distribuiti.E-mail: [email protected]

architettureinformatiche...

Documents