UNIVERSITA DEGLI STUDI DI BOLOGNA

UNIVERSITA DEGLI STUDI DI BOLOGNA FACOLTA DI INGEGNERIA Corso di Laurea in Ingegneria Informatica I web services come soluzione per làinteroperabilita e làinterazione automatica fra sistemi software Tesi di Laurea di: Stefano Ricciarelli Relatore: Prof. Antonio Natali Correlatori: Prof. Enrico Denti Ing. Luca Bicci Anno Accademico 2001-2002

Parole chiave WEB SERVICES DESCRIZIONE DI SERVIZI INTEROPERABILITA CROSS-PLATFORM DISCOVERY AGENCY BUSINESS PROCESS

Indice CAPITOLO 1 PRESENTAZIONE 1 1.1 INTRODUZIONE 1 1.1.1 INTEGRAZIONE E COSTO DEL SOFTWARE 1 1.1.2 UN NUOVO MIDDLEWARE PER UN CONTESTO GLOBALE 2 1.1.3 I WEB SERVICES 3 1.2 OBIETTIVI 5 1.3 IL CASE STUDY EBROKER 6 CAPITOLO 2 WEB SERVICES: MODELLO ARCHITETTURALE E STANDARD TECNOLOGICI 9 2.1 CONTESTO DI STANDARDIZZAZIONE 9 2.2 I WEB SERVICES: DEFINIZIONE E ARCHITETTURA 12 2.2.1 DEFINIZIONE DI WEB SERVICE 12 2.2.2 IL METALINGUAGGIO XML 13 2.2.3 ARCHITETTURA CONCETTUALE E SCENARIO DI RIFERIMENTO 14 2.3 WEB SERVICES STACKS 15 2.3.1 WIRE STACK 16 2.3.2 SOAP 17 2.3.3 DESCRIPTON STACK 20 2.3.4 WSDL 22 v

Indice CAPITOLO 3 PROGETTO DEL WEB SERVICE EBROKER: ANALISI CONCETTUALE E PROBLEMATICHE COINVOLTE 25 3.1 INTRODUZIONE 25 3.2 DESIGN PATTERNS 25 3.2.1 PATTERN DI PROGETTAZIONE PER IL CASE STUDY 26 3.3 PROGETTAZIONE 27 3.3.1 WORKFLOW DI PROGETTAZIONE DI UN WEB SERVICE 28 3.3.2 INFRASTRUTTURE DI SUPPORTO PER LO SVILUPPO DI WEB SERVICES 30 3.3.3 WSDL COME LINGUAGGIO INTERMEDIO PER LA GENERAZIONE DI STUBS E TIES 30 3.4 PIATTAFORMA TECNOLOGICA DI RIFERIMENTO 31 3.4.1 JAX-RPC 32 3.4.2 APACHE AXIS 36 3.5 ANALISI DELLE PROBLEMATICHE COINVOLTE NEL SERVIZIO EBROKER 38 3.5.1 DEFINIZIONE DELLE FUNZIONALITA DEL WEB SERVICE DA ESPORRE 39 3.5.2 DEFINIZIONE DEI TIPI XML SCHEMA 40 3.5.3 SEMANTICA IMPLICITA DEI DATI 42 3.5.4 RECUPERO DELLA SEMANTICA DEI DATI 43 CAPITOLO 4 SVILUPPO DELLA SOLUZIONE PER IL CASE STUDY 45 4.1 SERIALIZER E DESERIALIZER 45 4.2 WEB SERVICE DEPLOYMENT DESCRIPTOR 46 4.3 GENERAZIONE AUTOMATICA DEL WSDL 48 4.4 IMPLEMENTAZIONE DELLA SOLUZIONE 49 4.4.1 IL WEB SERVICE E IL MAPPING DEI DATI 49 4.4.2 UTILIZZO DEI SERIALIZZATORI FORNITI DA AXIS 51 4.4.3 PRIMA SOLUZIONE IMPLEMENTATIVA PER IL CASE STUDY 52 4.5 IMPLEMENTAZIONE DEL CLIENT IN JAVA 55 vi

Indice 4.6 TESTING 58 4.7 CARENZE SEMANTICHE E SECONDA SOLUZIONE IMPLEMENTATIVA 63 4.7.1 LIMITI SEMANTICI DELLA PRIMA SOLUZIONE 63 4.7.2 DIFFERENZIAZIONE DELLE HASHTABLE 65 4.8 UNA SOLUZIONE COMPLETA 71 4.8.1 GENERAZIONE AUTOMATICA DEL CORRETTO WSDL 71 4.8.2 CONSIDERAZIONI CONCLUSIVE 71 4.9 SVILUPPO DI UN CLIENT SU PIATTAFORMA MICROSOFT.NET 72 4.9.1 PROGETTO DEL CLIENT SULLE TECNOLOGIE MICROSOFT.NET 72 4.9.2 IMPLEMENTAZIONE C# E ASP.NET CON VISUAL STUDIO.NET 74 4.9.3 LIMITI RISCONTRATI 75 4.9.4 REQUISITI PER LO SVILUPPO DI UNA NUOVA SOLUZIONE COMPATIBILE CON.NET 75 4.9.5 DEFINIZIONE DI UNA DESCRIZIONE WSDL COMPATIBILE CON.NET 76 4.9.6 DEFINIZIONE DEI DATI COME ARRAY SOAP 79 4.9.7 IMPLEMENTAZIONE E TESTING CON CLIENT MICROSOFT.NET 82 CAPITOLO 5 DISCOVERY AGENCY E INTERAZIONE AUTOMATICA 87 5.1 DISCOVERY AGENCY 87 5.1.1 INTRODUZIONE 87 5.1.2 DISCOVERY AGENCY STACK 88 5.2 REGISTRI UDDI 90 5.2.1 STRUTTURA DI UN REGISTRO UDDI 91 5.2.2 MODELLO DI FUNZIONAMENTO DI UDDI 92 5.3 OLTRE LàINTEROPERABILITA 93 5.3.1 UN NUOVO SCENARIO 93 5.3.2 STANDARDIZZAZIONE PER UNA INTERAZIONE AUTOMATICA 94 5.3.3 ORGANISMI INTERNAZIONALI DI STANDARDIZZAZIONE 95 5.3.4 ANALISI DEL RUOLO DELLA SEMANTICA NELLA COMUNICAZIONE 96 5.4 NUOVE FRONTIERE DELLA SEMANTICA 98 vii

Indice CAPITOLO 6 WEB SERVICES E BUSINESS PROCESS 103 6.1 INTERAZIONE GUIDATA DI WEB SERVICES 103 6.2 WEB SERVICES E BUSINESS PROCESS 104 6.3 WSCI 106 6.4 BPEL4WS 108 6.4.1 IL LINGUAGGIO 108 6.4.2 UN ESEMPIO CONCRETO 109 6.4.3 BPEL4WS E SPECIFICHE ULTERIORI 113 6.5 POTENZIALITA DEL BUSINESS PROCESS E DI BPEL4WS 114 CAPITOLO 7 SINTESI E CONCLUSIONI 117 7.1 SINTESI 117 7.1.1 I WEB SERVICES 117 7.1.2 PROGETTAZIONE 118 7.1.3 SVILUPPO DELLA SOLUZIONE 120 7.1.4 I WEB SERVICES OLTRE LèINTEROPERABILITA 123 7.2 CONCLUSIONI 125 APPENDICE A - SOLUZIONE FINALE PER LA PIATTAFORMA JAVA 129 DESCRIZIONE WSDL DEL WEB SERVICE 129 DOCUMENTO WSDD PER IL DEPLOYMENT 131 ESEMPIO DI MESSAGGIO SOAP 132 viii

Indice APPENDICE B ésoluzione FINALE PER LàINTEROPERABILITA CON LA PIATTAFORMA.NET 137 DESCRIZIONE WSDL DEL WEB SERVICE 137 DOCUMENTO WSDD PER IL DEPLOYMENT 140 ESEMPIO DI MESSAGGIO SOAP 141 BIBLIOGRAFIA 147 RINGRAZIAMENTI 155 ix

Capitolo 1 Presentazione 1.1 Introduzione 1.1.1 Integrazione e costo del software Secondo un tendenza ormai consolidata, negli ultimi anni si e assistito al progredire di una forte introduzione dellèelaborazione digitale che arriva ormai a coinvolgere qualunque categoria di business, e si spinge fino a fornire un supporto per ogni singola attivita allèinterno dello specifico business. Di fronte a questo fenomeno ù per il quale, ad oggi, non emergono ragioni per ipotizzare unèinversione di tendenza ù il mondo dellèinformation tecnology ha prodotto una serie di soluzioni specifiche che si sono tradotte in una moltitudine di sistemi software. Il risultato di questo processo e una sostanziale diversificazione delle soluzioni che ha reso i sistemi software sempre piu eterogenei e complessi, a causa della pluralita di sistemi operativi, sistemi informativi, linguaggi di programmazione e tecnologie adottate. In un simile contesto, nel momento in cui si passa da unèelaborazione centralizzata e confinata ad unèesigenza di comunicazione fra sistemi, emerge in modo evidente un forte problema di integrazione fra questi sistemi. Lèelevato dinamismo del mondo dellèinformation tecnology, con il rapido e continuo sviluppo di nuove soluzioni, ha tuttavia evidenziato costi spesso proibitivi nel momento in cui lèadozione di una nuova tecnologia comportava lèintegrazione con tutti i sistemi preesistenti. La necessitadi fornire una risposta alla sfida dellèintegrazione a costi ragionevoli ha portato allo sviluppo del concetto di middleware, ossia di uno strato logico 1

Capitolo 1 applicativo in grado di fare da ponte fra sistemi eterogenei, grazie allèadozione di un linguaggio comune per lo scambio di dati e per lèinvocazione di operazioni. Il middleware diventa quindi il collante del sistema informativo, realizzando esso stesso unèinfrastruttura di comunicazione efficace fra applicazioni. Una piattaforma di middleware fornisce un linguaggio intermedio di specifica per la definizione dei tipi di dato e delle funzionalitacondivise, nonch un sistema di traduzione fra la piattaforma concreta di implementazione e il livello di specifica offerto dal middleware. Un middleware puo inoltre fornire un insieme aggiuntivo di funzionalitaad alto valore, quali la gestione di un sistema di nomi per la pubblicazione e la ricerca di servizi, o la realizzazione di un sistema per la gestione delle transazioni. [1] [5] 1.1.2 Un nuovo middleware per un contesto globale Negli ultimi anni sono apparse diverse piattaforme middleware, fra le quali la piu nota e probabilmente CORBA, sviluppata nel 1999 da OMG. Ma anche grandi aziende software hanno sviluppato dei prodotti che interpretano il concetto di middleware, come la specifica Enterprise Java Bean di SUN e DCOM di Microsoft. Indubbiamente queste proposte hanno costituito una risposta alle necessitae ai costi di integrazione, ma hanno anche rappresentato unèulteriore nuova tecnologia da integrare allèinterno del sistema informativo, con nuovi costi e necessita di apposite figure professionali a causa della complessita di queste soluzioni. Complessita che, assieme alla mancanza di un solo standard universale, aumenta il rischio collegato alla loro adozione. Parallelamente, la domanda di integrazione e ulteriormente cresciuta, ma soprattutto e il contesto ad essere cambiato, assumendo una connotazione sempre piu globale e distribuita. Di fronte ad esso, i sistemi presenti si sono dimostrati troppo rigidi, poich costituiti di componenti eccessivamente integrati e dipendenti fra loro, con una conseguente ripercussione sui costi collegati ad una qualche modifica allèinterno del sistema. Un particolare risalto a queste problematiche deriva poi dal rapido sviluppo di un e-business B2B ubiquo attraverso internet che ha 2

Presentazione determinato, o andraa determinare nel prossimo futuro, il fallimento delle architetture monolitiche, spingendo nella direzione di sistemi sempre piu loosely coupled. Questi sistemi, per loro natura, rispondono meglio alle esigenze della prossima generazione di e-business, poich hanno nelle loro caratteristiche fondamentali la flessibilita: essendo infatti sistemi maggiormente confinati, sono in grado di sopportare cambiamenti senza che questi si ripercuotano a cascata su una serie di altri sistemi. Il mutato scenario prefigura quindi lo spazio per un middleware di nuova concezione capace di raccogliere la forte necessitadi interoperabilita allèinterno di un contesto globale, distribuito ed eterogeneo, come quello posto in essere dalla nuova generazione di e-business. [5] [3] 1.1.3 I web services Nello scenario analizzato, le nuove tecnologie dei web services si pongono come le piu accreditate per interpretare questa evoluzione di middleware, ponendosi alla base di una sfida estremamente ambiziosa: rappresentare per lèinterazione programma-programma quello che oggi rappresenta il web per lèinterazione utente-programma. Il che significa costituire uno standard universale per la comunicazione fra programmi. Un simile traguardo rende indispensabile la presenza di fattori altamente qualificanti, capaci di determinare per questa tecnologia il raggiungimento di un tale successo. Fra questi fattori, quello essenziale riguarda la volonta, di carattere politico, delle maggiori aziende impegnate nellèambito della realizzazione di soluzioni software, a convergere verso uno standard comune, rinunciando alle tecnologie proprietarie sulle quali sono state investite ingenti risorse. E difficile avanzare delle previsioni su considerazioni di questo tipo, tuttavia oggi si assiste ad un atteggiamento diverso rispetto al passato, poich la storia ha dimostrato che lèadozione di standard pubblici ha sempre determinato un abbassamento dei costi e una migliore interoperabilita, indispensabile per lèintegrazione fra aziende in quel processo che prende il nome di Business-to-Business Integration (B2Bi). Questo nuovo atteggiamento ha determinato il raggiungimento di un consenso decisamente ampio sui web services, che arriva a contare un numero di aziende e organizzazioni ragguardevole: basti considerare, a 3

Capitolo 1 titolo esemplificativo, che il WS-I 1 consta giadi piu di un centinaio delle maggiori aziende operanti nellèinformation tecnology. Inoltre, almeno per quanto riguarda i livelli di base, gli standard dei web services, seppure nati in ambiti proprietari (principalmente IBM e Microsoft), sono gestiti da organismi internazionali indipendenti che ne garantiscono uno sviluppo autonomo, ma soprattutto li rendono di domino pubblico e esenti da royalty; fatto di indubbia importanza nel momento in cui si vogliono affermare queste nuove tecnologie a livello universale. Oltre al contesto di standardizzazione decisamente diverso da quello delle precedenti infrastrutture middleware, i web services si distinguono per la nuova architettura che propongono e per le tecnologie di base sulle quali essa e sviluppata. Rimandando al capitolo 2 per un approfondimento di questi temi, va sottolineato come un carattere distintivo dei web services sia la semplicita. Semplicita che si traduce indubbiamente in una piu limitata gestione degli aspetti inerenti le comunicazioni fra componenti, ma che, proprio per questo, apre la strada ad una piu ampia diffusione e adozione di queste tecnologie, che non costituiscono piu una prerogativa riservata alle sole grandi aziende dotate di adeguati sistemi software. Inoltre, la strutturazione a stack ù similmente a quanto avviene con lo standard OSI nelle comunicazioni ù garantisce una modularita tale da consentire lo sviluppo futuro di funzionalita piu avanzate che possono erigersi a partire dai protocolli di piu basso livello. Infatti, dopo avere ormai delineato definitivamente la parte fondamentale dello stack dei web services, e questa la direzione che si sta attualmente percorrendo, con particolare interesse a quegli aspetti di gestione delle transazioni e di Business Process Management (BPM) per i quali le precedenti infrastrutture hanno prodotto soluzioni molto valide. Unèultima importante caratteristica da evidenziare riguarda il salto qualitativo realizzabile attraverso lèarchitettura service-oriented dei web services 2 rispetto ai sistemi object-oriented tradizionali. Questa architettura promuove infatti lo sviluppo di componenti software loosely coupled in grado di interagire in modo del tutto dinamico e non noto a priori, tanto da parlare di Just-in-time integration. Inoltre, in un mondo di web services, si 1 Organismo internazionale per la promozione dellèinteroperabilitafra web services. 2 Per la descrizione di questa architettura si faccia riferimenti ai capitoli 2 e 5. 4

Presentazione modifica il significato di progettare applicazioni, che si traduce nella descrizione della capacitadi una rete di web services di realizzare una funzionalitadesiderata, mediante lèorchestrazione di detti componenti. [2] [3] [4] 1.2 Obiettivi Da quanto discusso, si evince che il mondo dellèintegrazione fra applicazioni eterogenee sta subendo un importante stadio evolutivo, che comporteraun diverso modo di sviluppare e pensare tali applicazioni. E questa la considerazione che costituisce la cornice in cui si inserisce il presente lavoro di ricerca e sviluppo, effettuato in collaborazione con la Capecod di Imola (BO), che si pone lèobiettivo di analizzare le nuove tecnologie dei web services, al fine di comprendere e valutare il loro impatto nello sviluppo del software. In primo luogo si vuole quindi procedere ad uno studio di dette tecnologie per comprendere tanto gli aspetti concettuali legati al modello architetturale proposto, che gli aspetti tecnologici connessi agli standard dei web services. Da questa analisi si vuole produrre una valutazione ù che non deve prescindere dagli aspetti, meramente pratici, connessi ai prodotti software reali che attualmente interpretano queste tecnologie ù sugli effettivi benefici e sui costi che lèadozione dei web services comportano nello sviluppo del software. Una simile valutazione ragionata non puo esimersi dal misurarsi con un contesto reale di sviluppo, attraverso il quale testare le effettive problematiche che emergono nella realizzazione di web services. A tale scopo, si e quindi deciso di concretizzare lèanalisi su un case study che potesse essere significativo nello scenario di sviluppo dei web services. Questa necessita si e favorevolmente incontrata con lèesperienza dellèazienda nella realizzazione di soluzioni software in contesti eterogenei, offrendo col componente software EBroker un valido e interessante case study. La scelta di un componente legacy, ossia sviluppato senza unèottica pregressa di web service, rende particolarmente significativo il lavoro da intraprendere, poich consente unèeffettiva misurazione del costo di integrazione delle nuove tecnologie col software esistente. 5

Capitolo 1 1.3 Il case study EBroker Il software EBroker sviluppato da Capecod si propone come soluzione ad una delle esigenze piu sentite nello sviluppo delle business application aziendali, costituita dalla necessitadi integrare sistemi eterogenei in modo semplice e parametrico, risolvendo lèaspetto critico del trattamento di tutte le attivitadi comunicazione e scambio dati fra i differenti sistemi. A questo scopo lo EBroker viene installato allèinterno delle aziende come un unico modulo software, che costituisce un componente centralizzato attraverso il quale gestire tutte le comunicazione dati. Di questo componente lèazienda ha realizzato piu implementazioni con diverse tecnologie quali Java,.NET e Lotus Domino, per integrarsi al meglio con le diverse piattaforme. Se quindi attualmente lo EBroker e un componente centralizzato e confinato, il nuovo obiettivo che si pone e quello di renderlo aperto allèesterno, o per farlo interagire con un altro EBroker che gestisce dati di unèaltra realta, oppure per rendere disponibili i dati a componenti diversi che debbano attingervi per determinate operazioni. Si vuole cioe realizzare unèinterfaccia attraverso la quale potere importare e esportare dati da e verso componenti eterogenei esterni allèambito gestito dallo EBroker. Si intuisce come il contesto estremamente eterogeneo in cui si opera suggerisca lèadozione delle tecnologie dei web services per ottemperare allo scopo. La piattaforma di sviluppo e testing dei web services descritta si configura quindi come coerente con le tematiche per le quali i web services si propongono, nonch particolarmente adatta per stressare queste tecnologie dal momento che le strutture dati gestite dallo EBroker sono particolarmente complesse. Per quanto riguarda gli aspetti implementativi, ragioni interne dellèazienda hanno portato a prediligere la versione Java dello EBroker quale realizzazione deputata ad essere dotata di unèinterfaccia conforme ai web services. Contestualmente si e previsto lo sviluppo di un client Java attraverso il quale svolgere una prima fase di testing. Fra gli obiettivi e stato successivamente introdotto lo sviluppo di un client su piattaforma Microsoft.NET al fine di valutare lèinteroperabilita ottenibile, eventualmente previa realizzazione di modifiche alla precedente versione, 6

Presentazione qualora si rendessero necessarie per giungere ad una interoperabilita completa ed effettiva. [6] 7

Capitolo 2 Web Services: modello architetturale e standard tecnologici 2.1 Contesto di standardizzazione Prima di addentrarsi nella descrizione architetturale e tecnologica dei web services, occorre porre attenzione al contesto di standardizzazione nel quale essi si sviluppano, poich questo influisce in modo determinante sulla diffusione di queste tecnologie e conseguentemente sulla loro appetibilita. Nel precedente capitolo si sono esaminate le ragioni e la storia evolutiva dei web services sotto la spinta delle nuove esigenze emergenti in ambito B2B. Tali esigenze hanno portato alla realizzazione di soluzioni, modelli e protocolli in grado di fornire una risposta valida alle problematiche emerse. Risposta che nasce inizialmente nellèambito di ricerche proprietarie, ad opera di gruppi di lavoro di alcune grandi aziende software, e che presenta alcune lacune dal punto di vista di una chiara e complessiva visione architetturale e concettuale delle tecnologie dei web services. Dèaltronde la nascita di una nuova tecnologia segue frequentemente un simile iter di sviluppo, specialmente quando essa interessa un contesto globale, sul quale quindi vengono convogliate un insieme di proposte e sviluppi ad opera di una moltitudine di soggetti: un chiaro esempio puo essere scorto nellèevoluzione travagliata che ha seguito il linguaggio HTML prima di giungere ad una versione definitiva, che peraltro porta i segni di uno sviluppo tuttèaltro che lineare. Un ruolo chiave giocato nella definizione della piattaforma e quindi indubbiamente costituito dagli organismi internazionali di 9

Capitolo 2 standardizzazione. Si tratta di un tema che coinvolge una serie di problematiche che esulano dal presente lavoro, ma i cui riflessi pesano indubbiamente sulla rapidita con cui questi standard giungono a maturazione. Non sfugge infatti di notare come SOAP ù il protocollo di base dei web services, il cui stato embrionale risale al 1998 ù giunga ad una definizione standard, affidata al W3C, solo alla fine del 2001, che ha attualmente raggiunto il grado di Candidate Recommendation. Ma lo stato di avanzamento degli altri protocolli collegati ai web services e ancora piu ritardato, e se il W3C assegna ancora a WSDL 1.2 il grado di Working Drafts, ai livelli alti dello stack dei web services si assiste ad una pluralita di proposte proprietarie contrastanti che sono lontane dal convergere rapidamente in uno standard condiviso. A complicare ulteriormente questo scenario, va considerato che il W3C non e lèunico organismo internazionale coinvolto nellèopera di standardizzazione, dal momento che i web services abbracciano piu settori dellèinformation tecnology oltre allo sviluppo del web, primo fra tutti il commercio elettronico B2B. Nella successiva tabella 2.1 si tenta di fornire un quadro sintetico dei principali organismi e gruppi di lavoro che, a vario titolo, interessano lèambito dei web services W3C OASIS World Wide Web Consortium. E lèorganismo principe per lo sviluppo e la standardizzazione delle tecnologie collegate al web, prime fra tutte XML. Nel 2002 ha avviato unèattivita specifica per i web services che ha provveduto alla standardizzazione di WSDL e SOAP. I protocolli pubblicati sono di dominio pubblico allo scopo di favorire il libero sviluppo del web. Di rilievo per i web services sono anche gli standard inerenti la sicurezza e, anche se in fase preliminare, lèorchestrazione. Organization for the Advancement of Structured Information Standards. E un consorzio internazionale che raccoglie piu di 600 membri e 100 nazioni, con lo scopo di guidare lo sviluppo e lèadozione di standard per il commercio elettronico. Al proprio interno sponsorizza molti standard, essenzialemente basati su XML, fra i quali, di particolare interesse per i web services, 10

I Web Services ebxml UDDI WS-I UDDI. Electronic Business using XML. E un insieme di specifiche sponsorizzate congiuntamente da OASIS e da UN/CEFACT (il centro per il commercio elettronico delle Nazioni Unite) allo scopo di fornire unèinfrastruttura aperta, basata su XML, in grado di garantire un metodo standard per lo scambio di informazioni di e-business. Queste specifiche non nascono nel contesto dei web services e per alcuni aspetti sono ad essi antagoniste, in particolare nella definizione di un registry e di standard per il Business Process Management. Universal Description Discovery and Integration. Standard per la realizzazione di un registro universale in grado di supportare il publishing e discovering di web services. Questo standard e supportato dalle piu importanti aziende interessate nel commercio elettronico. Web Services Interoperability Organization. Si tratta di unèorganizzazione recente ma molto importante, perch costituita dai piu significativi operatori nel campo dei web services, al fine di promuovere unèinteroperabilitaeffettiva fra le diverse implementazioni degli standard dei web services. Tabella 2.1 ù Organismi interessati nello sviluppo degli standard collegati ai web services. Anche se il quadro di standardizzazione appare complesso e lungi dallèaver raggiunto la creazione di unèarchitettura aperta, globale e universalmente condivisa, e altrettanto vero che le tecnologie di base hanno raggiunto un certo grado di maturita, come testimoniato da SOAP e WSDL che sono a pieno titolo dei linguaggi aperti e royalty-free, il cui sviluppo e gestito dal W3C. Decisamente piu controversa e invece la questione sui linguaggi di piu alto livello, maggiormente inerenti le tematiche tipiche dei contesti B2B; si avramodo di approfondire la questione nel capitolo 6. Se quindi uno standard de jure puo dirsi ancora in corso di definizione, e tuttavia possibile affermare che le tecnologie dei web services costituiscono indubbiamente, almeno negli aspetti di base, uno standard de facto, in virtu del numero di organizzazioni e aziende 11

Capitolo 2 coinvolte, comprendenti i piu importanti nomi del mondo del software e dei servizi, nessuno escluso (Microsoft, IBM, BEA System, SUN,...). I successivi paragrafi, cui e deputato il compito di fornire una panoramica sullèarchitettura e sullèattuale insieme di tecnologie dei web services, rispecchiano la situazione di transizione descritta ed illustrano tanto i tentativi di definizione di una architettura organica, quanto la tecnologia che si e andata formando, fra i quali non mancheranno delle dissonanze. 2.2 I web services: definizione e architettura 2.2.1 Definizione di web service Col termine web service si e soliti riferirsi ad un insieme di tecnologie e architetture ù piu in generale ad uno spazio concettuale ù che cattura le idee di: oggetti distribuiti e integrazione di applicazioni, tipiche dei contesti applicativi e di programmazione; scambio di dati eterogenei attraverso la rete, tipico dei contesti EDI e B2B; World Wide Web, come rete globale capace di offrire servizi ai suoi utenti. Tuttavia per una definizione piu precisa si puo ricorrere a quella sviluppata dal W3C: un web service e un sistema software, identificato da un URI, che presenta interfacce e binding descritti in XML. La definizione del web service puo essere ottenuta da altri sistemi software attraverso un processo di discovery; successivamente tali sistemi possono interagire col web service secondo le modalita previste dalla sua definizione mediante scambio di messaggi XML veicolati da protocolli internet-based. 12

I Web Services Si tratta di una definizione generale che prescinde dai particolari dei protocolli di funzionamento quali SOAP e WSDL, ma che evidenzia chiaramente i concetti fondamentali dellèarchitettura. Anzitutto si parla esplicitamente di internet e di URI, il che colloca immediatamente i web services in un contesto globale ed eterogeneo, avvalorato dallèutilizzo di XML. Si chiarisce poi la necessita di disporre di unèinterfaccia atta a specificare le modalita di interazione del web service con altri sistemi software; si fa infine riferimento esplicito a meccanismi di discovery connotando in tal modo i web services come sistemi loosely coupled. [7] 2.2.2 Il metalinguaggio XML Non si deve mancare di notare lèesplicito riferimento a XML nella definizione di web service. Potrebbe apparire come un mero rimando tecnologico, ma in realta ne costituisce uno degli aspetti fondamentali, capace di decretare il successo dei web services. Infatti, lèelevatissimo consenso che si e andato formando attorno a XML negli ultimi anni, fa sı che esso possa rappresentare quel linguaggio intermedio per la rappresentazione dei dati e dei servizi, indispensabile per dominare lèeterogeneitadei sistemi. E questo un aspetto cruciale per le tematiche connesse ad una integrazione di livello globale, come discusso ampiamente nel capitolo 1. Lèimportanza di XML allèinterno della tecnologia dei web services e tale che e difficile affermare se sono i web services a trarre vantaggio da XML, o se, viceversa, essi non sono che la nuova ed ennesima applicazione cui XML ha dato origine. A prescindere da questo genere di considerazioni, va rilevato come XML sia presente a tutti i livelli della struttura a stack dei web services, i cui linguaggi sono tutti derivati da questo metalinguaggio. Ma XML gioca un ruolo estremamente importante ù questo lavoro di ricerca avraampio modo di metterlo in risalto ù anche nella definizione dei tipi di dato scambiati dai web services che vengono definiti attraverso un documento XML Schema. 13

Capitolo 2 2.2.3 Architettura concettuale e scenario di riferimento Lèarchitettura concettuale dei web services pone lèaccento sul concetto di servizio, ed e pertanto indicata col nome di Service Oriented Architecture. Tale architettura e espressa dalla figura 2.1 nella quale si evidenziano le tre entitafondamentali del modello di servizio proposto: service requestor: chi necessita del servizio svolto dal web service; service provider: chi gestisce la richiesta al servizio (da un punto di vista architetturale si tratta della piattaforma che ospita lèimplementazione del web service); discovery agency: lèentitache si occupa di mantenere e rendere disponibili per ricerche le descrizioni dei servizi. Figura 2.1 ù Architettura concettuale dei web services. Lo scenario cui si fa riferimento per questa architettura prevede che il service provider produca una descrizione del servizio che ospita e che la pubblichi in un qualche registro. A tale registro faranno riferimento i service requestor per ricercare il servizio da essi desiderato, quindi, successivamente, dialogheranno direttamente col service provider opportuno dando luogo allèinterazione necessaria per portare a compimento 14

I Web Services lèoperazione desiderata. Un simile scenario, ancorch semplice e intuitivo nei suoi tratti essenziali, comporta tuttavia diverse problematiche di natura tecnica, ma soprattutto concettuale, la cui disamina sara affrontata nel capitolo 5. Service requestor e service provider sono da intendersi come agenti software che richiedono o forniscono servizi; trattandosi di ruoli puramente logici, ogni agente puo trasformarsi da requestor a provider e viceversa. Le comunicazioni fra i precedenti agenti software non sono vincolate ad uno specifico pattern di interazione: tipicamente si trattera di unèinterazione request/response, ma sono altresı valide interazioni mediante messaggi one-way, oppure broadcast. E inoltre possibile che fra service requestor e service Provider siano presenti degli intermediari che non modificano la comunicazione ma che possono svolgere altri ruoli come quello di routing dei messaggi. [7] [2] 2.3 Web services Stacks Delineata lèarchitettura di base e il modello di servizio, il passo successivo consiste nellèadozione di particolari linguaggi mediante i quali le entita presentate siano in grado di dialogare. Come chiaramente evidenziato nella definizione di web service, si tratta di linguaggi direttamente derivati da XML e quindi definiti nella loro struttura sintattica attraverso un XML Schema. La prima questione rilevante da affrontare consiste nello stabilire quali funzionalitadebbano offrire questi linguaggi. Il protocollo di interazione fra requestor e provider, per esempio, deve offrire funzionalita di messaggistica asincrona, di routing, di sicurezza, di sessione? E la descrizione di un servizio in cosa consiste? Fino a quale grado di dettaglio deve spingersi? La risposta a queste domande consiste in una architettura a stack ù similmente a quanto accade nella comunicazione strutturata dai livelli OSI ù in cui ad ogni livello e assegnata una funzionalitache sara utilizzata dal livello superiore. In questo modo si riesce ad aggredire per gradi la complessitadel modello di interazione, evidenziando competenze distinte per le quali sviluppare linguaggi specifici. 15

Capitolo 2 Discovery Agency Stack Description Stack Wire Stack Security Management QoS Figura 2.2 ù Stack di base dellèarchitettura dei web services. Cio consente di implementare, a seconda degli scenari, solo alcuni dei livelli dellèintero stack, consentendo cosı quella semplicita, fondamentale per garantire unèampia adozione di queste tecnologie, cui si accennava nel capitolo 1 in antitesi a sistemi middleware ben piu complessi. Lo stack proposto e abbastanza articolato e conta diversi livelli raggruppati in tre stack di base come rappresentato in figura 2.2. Si noti come alcune problematiche, quali la sicurezza, QoS e management non trovino un riscontro preciso in un apposito livello dello stack che le gestisca interamente; piuttosto si puo affermare che ogni livello dovrafornire dei meccanismi atti al conseguimento complessivo di questi scopi. Questa scelta si rende nuovamente necessaria per garantire una struttura di base sufficientemente flessibile e semplice; infatti la gestione delle precedenti tematiche in un contesto cosı eterogeneo come quello dei web services si tradurrebbe in sostanziale appesantimento dei protocolli, inutile laddove tali caratteristiche non siano richieste. Nei successivi paragrafi si discuteranno solo i primi due livelli, rimandando la discussione del livello di discovery al capitolo 5. [7] 2.3.1 Wire Stack Il livello Wire e deputato alla realizzazione del trasporto fisico dei messaggi fra le entita in comunicazione, e puo essere ulteriormente raffinato in tre sotto livelli, come evidenziato nella figura 2.3. Il primo livello e costituito dal trasporto che deve consentire al web service di essere accessibile agli altri sistemi attraverso la rete; caratteristica, questa, imprescindibile per un web service. Vista lèubiquita 16

I Web Services del World Wide Web e dei suoi protocolli di base, il trasporto sara realizzato quasi certamente dal protocollo HTTP, anche se cio non e vincolante e FTP o SMTP sono protocolli ugualmente accettabili. In contesti non globali, quali possono essere le reti intranet aziendali, si possono utilizzare invece infrastrutture di trasporto specifiche quali, ad esempio, MQSeries o CORBA; si tratta di decisioni che possono essere dettate da particolari requisiti applicativi in termini di sicurezza, performance, availability, reliability. Wire Stack Extensions Packaging Transport SOAP Features MIME, DIME, SOAP HTTP, SMTP, TCP Figura 2.3 ù Raffinamento del livello Wire. A fianco di ciascun livello sono indicate alcune possibili realizzazioni tecnologiche. Al successivo livello di Packaging e demandato il compito di impacchettare le informazioni, mentre il livello Extension prevede la possibilitadi aggiungere informazioni ortogonali al messaggio necessarie al fine di raggiungere un determinato scopo; tali informazioni non sono predeterminate, e possono riguardare un qualsiasi aspetto come ad esempio il routing o la sicurezza. Questi due livelli vengono realizzati attualmente dal protocollo SOAP che, sebbene non rappresenti lèunica soluzione possibile, e a tutti gli effetti il protocollo standard di comunicazione dei web services. [7] 2.3.2 SOAP SOAP ù ovvero Simple Object Access Protocol ù e un protocollo semplice, leggero, basato su XML, per lo scambio di informazioni strutturate in un sistema decentralizzato e distribuito. Nasce allèinterno di Microsoft nel 1998, viene reso pubblico nel tardo 1999 e finalmente nel maggio del 2000 approda al W3C sostenuto da UserLand, Ariba, Commerce One, Compaq, Developmentor, HP, IBM, IONA, Lotus, 17

Capitolo 2 Microsoft e SAP. Il protocollo diviene quindi di pubblico dominio, esente da royalty, e il suo sviluppo prosegue allèinterno del W3C giungendo alla versione 1.2 del dicembre 2001 ù divenuta Candidate Recommendation nel dicembre 2002 ù che rappresenta il mattone fondamentale per la realizzazione di web services, costituendone il substrato di comunicazione. Il protocollo non definisce alcuna semantica applicativa, bensı propone dei meccanismi per lo scambio dei messaggi sufficientemente generici al fine di rendere SOAP utilizzabile in una grande varieta di sistemi. Questo protocollo e costituito di tre parti: la definizione del SOAP Envelope, ossia di quel documento XML che costituisce il messaggio SOAP; la specifica delle SOAP Encoding Rules, ossia di regole che consentono di serializzare in un documento XML un grafo di dati; la definizione di convenzioni per realizzare una semantica RPC attraverso lo scambio di messaggi SOAP. Il SOAP Envelope ù cioe il messaggio SOAP ù e costituito da un Body contenente il messaggio vero e proprio e, opzionalmente, da un Header che realizza il livello di Extension descritto nel precedente paragrafo, rappresentando il meccanismo di estensione di SOAP. Al suo interno infatti possono comparire elementi di qualunque genere il cui attributo MustUnderstand specifica se chi deve gestire il messaggio SOAP ù il destinatario, ma eventualmente anche un nodo intermedio ù e tenuto a conoscerne la semantica: in caso affermativo dovra operare di conseguenza, altrimenti dovragenerare un messaggio di tipo SOAP Fault se non in grado di comprendere la semantica dellèelemento in questione. Il seguente listato riporta un esempio di un semplice messaggio SOAP. 18

I Web Services <SOAP-ENV:Envelope xmlns:soap- ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP- ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Header> <t:transaction xmlns:t="some-uri" SOAP-ENV:mustUnderstand="1"> 5 </t:transaction> </SOAP-ENV:Header> <SOAP-ENV:Body> <m:getlasttradeprice xmlns:m="some-uri"> <symbol>def</symbol> </m:getlasttradeprice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Listato 2.1 ù Esempio di messaggio SOAP. La specifica del SOAP Body e invece fondamentalmente dettata dalle Encoding Rules che costituiscono il nucleo del protocollo, descrivendo come codificare i dati in XML. Queste regole si basano essenzialmente sulla specifica XML Schema sui tipi di dato 1, che viene utilizzata per stabilire tanto i tipi di dato elementari precodificati, quanto il meccanismo per definire nuovi tipi di dato complessi come aggregati, attraverso determinati operatori, dei tipi semplici. SOAP provvede inoltre a fornire una specifica per la definizione di array che si dimostra molto flessibile dal momento che in essi possono essere contenuti elementi di qualunque tipo, diversi fra loro; oppure puo essere specificato un tipo unico per gli elementi dellèarray. In ogni caso, qualunque valore presente in un messaggio SOAP, sia esso lèelemento di un array o di un tipo complesso, puo contenere contestualmente il proprio tipo. Questa caratteristica offre il supporto al polimorfismo dei dati, dal momento che il tipo effettivo non e statico, ossia determinato dalla sola descrizione XML Schema del tipo, bensı, dinamicamente, puo essere presente unèistanza di un sottotipo 2. Per quanto riguarda infine le specifiche per realizzare meccanismi di RPC con SOAP, esse non sono altro che un insieme di convenzioni per codificare una chiamata ad un metodo in una struttura dati contenente i parametri di input/output del metodo. 1 XML Schema Part 2: Data Types, W3C, 2 maggio 2001, http://www.w3.org/tr/xmlschema-2/. 2 La relazione di sottotipo e determinata dallèutilizzo di appositi costrutti di XML Schema attraverso i quali viene definito un nuovo tipo come restrizione di un tipo esistente. Inoltre XML Schema prevede il tipo anytype che costituisce la radice di tutti i tipi, similmente a quanto rappresenta Object nei confronti degli altri oggetti di un linguaggio object oriented. 19

Capitolo 2 Rimandando ai riferimenti bibliografici per una descrizione piu approfondita del protocollo, deve comunque essere rilevato che le infrastrutture di supporto per lo sviluppo dei web services si occupano dellèintera gestione di questi aspetti di basso livello. Tuttavia, specialmente nel momento in cui emergano problemi di interoperabilitafra piattaforme di sviluppo diverse, lèanalisi del messaggio SOAP costituisce frequentemente un valido ausilio alla determinazione delle cause dei malfunzionamenti. Cio mette in luce un altro vantaggio innegabile dellèutilizzo di XML: la possibilita di essere compreso facilmente sia dallèuomo che dagli automi. Il rovescio della medaglia e costituito da unèinnegabile ridondanza di codifica che si traduce in messaggi SOAP particolarmente lunghi anche per piccole quantita di dati, assieme al maggiore tempo di elaborazione per il parsing del messaggio. Si tratta pero di un prezzo che si e disposti a pagare, perch ben inferiore ai costi tipicamente connessi allèinteroperabilitain contesti eterogenei. [8] [9] 2.3.3 Descripton Stack Decisamente piu complesso, almeno a livello concettuale, rispetto al Wire Stack, e lo stack che si occupa della descrizione di un web service. Anzitutto andrebbe chiarito che cosa si intende per descrizione, ossia quali sono gli aspetti che devono essere considerati per produrre una completa descrizione di un web service. La questione e evidentemente complessa, e al contempo estremamente rilevante, dal momento che, maggiore e la semantica che una descrizione riesce a fornire, maggiore e la capacita dei sistemi software di interagire tra loro in modo automatico, e minore la quantitadi conoscenza condivisa richiesta fra tali sistemi, che possono quindi essere sempre piu loosely coupled. Questa problematica, che costituisce il filo conduttore del lavoro di ricerca svolto, saraaffrontata piu dettagliatamente nel capitolo 5. In figura 2.4 si riporta invece la schematizzazione proposta dal W3C evidenziante i sotto livelli del Description Stack. Se il Wire Stack puo dirsi interamente coperto dai protocolli SOAP e HTTP, solo i primi tre livelli del Description Stack sono attualmente coperti da una soluzione tecnologica standard. In particolare, assumendo lo XML Schema come livello di descrizione dei tipi, il linguaggio WSDL 20

I Web Services copre i livelli di descrizione dellèinterfaccia ù in termini di messaggi attesi e restituiti ù e dellèimplementazione ù in termini di come codificare i messaggi e dove inviarli ù del web service. Per gli altri livelli, di seguito descritti, non si e ancora trovata una soluzione tecnologica consolidata e/o largamente condivisa. Description Stack Business Level Agreement Service Level Agreement Composition Orchestration Presentation Policy Implementation Description Interface Description XML Schema Figura 2.4 ù Raffinamento del livello Description. Il livello di Policy introduce un grado ulteriore di descrizione relativa al business di riferimento del web service (afferiscono a questo genere di descrizione le struttura dati presenti nei registri UDDI), alla QoS, al grado di sicurezza richiesto od offerto, e a requisiti di management. Questo livello presenta quindi evidentemente delle intersezioni con quegli aspetti di sicurezza, QoS e management che erano stati collocati a fianco dello stack dei web services (si veda figura 2.2). Il successivo livello di Presentation si discosta dagli altri poich specificatamente collegato allèinterazione con un attore umano; infatti esso si occupa di descrivere come renderizzare su schermo i messaggi di input/output dei web services. Infine, a completare il Description Stack, si trovano i livelli che si occupano di descrivere lèinterazione fra web services. Ai livelli di 21

Capitolo 2 Composition e Orchestration e assegnato il compito di descrivere come piu web services debbano interagire, al fine di raggiungere uno scopo piu complesso di quello realizzato singolarmente da ciascuno di essi. Si tratta di temi assai interessanti collegati ad aspetti di workflow e business process management per i quali si daraunèampia trattazione nel capitolo 6. Per quanto riguarda invece i livelli di Agreements essi, pur non risultando ancora definiti, sono affini ai precedenti e interessano gli aspetti contrattuali e legali che interessano lèinterazione fra web services. [7] 2.3.4 WSDL Il Web Service Description Language (WSDL) costituisce il linguaggio attraverso il quale descrivere lèinterfaccia di un web service. Si tratta di una necessitaimprescindibile per una infrastruttura di integrazione fra sistemi eterogenei quale e quella dei web services, poich fornisce la specifica per richiedere i servizi stabilendo il nome del servizio e il tipo di parametri di input/output attesi, in modo del tutto analogo a quanto avviene in CORBA con IDL. Figura 2.5 ù Contenuto di una descrizione WSDL. Il contenuto di una descrizione WSDL riporta informazioni relative allèinterfaccia del web service ma puo anche fornire informazioni circa una sua implementazione. Essendo, come SOAP e tutti i linguaggi utilizzati nellèambito delle tecnologie dei web services, un documento XML, le 22

I Web Services sezioni evidenziate nella figura 2.5 costituiranno gli elementi di questo documento XML. Il primo passo per descrivere lèinterfaccia di un web service consiste nel definire i tipi di dato che esso utilizza per il colloquio con gli altri sistemi. La sezione type si occupa proprio di questo aspetto e comprende al suo interno la definizioni di tipi di dato descritte mediante XML Schema. Definiti i tipi di dato si passa alla definizione dei messaggi che devono scambiarsi gli agenti della comunicazione. Questi messaggi rappresentano sostanzialmente le modalitadèinvocazione di un metodo (o funzione) e di consegna del risultato; infatti, tipicamente, per ogni metodo esposto vengono creati due messaggi aventi per nome, rispettivamente, il nome del metodo seguito da Request e da Response. Allèinterno del messaggio sono poi specificati i parametri che con esso debbono essere scambiati. La sezione porttype e invece quella che rappresenta la definizione vera e propria del servizio, espressa in termini di insieme di operazioni rese disponibili dal web service. Ognuna di queste operazioni e caratterizzata da un nome e da un messaggio di input e/o da uno di output. A seconda della presenza dei messaggi di input e/o output le operazioni possono essere suddivise nei seguenti quattro tipi: One-way: lèoperazione non prevede alcun messaggio di risposta. Request-response: lèoperazione, ricevuta la richiesta, invierala risposta. Solicit-response: lèoperazione prevede che sia lèendpoint ad inviare una richiesta; successivamente attende una risposta. Notification: lèoperazione prevede che lèendpoint invii un messaggio senza attendere alcuna risposta. Per quanto riguarda infine la sezione binding essa fa riferimento ad un porttype e specifica aspetti quali il formato dei messaggi e i dettagli del protocollo per le operazioni e i messaggi. Per uno stesso porttype possono essere presenti piu binding. La struttura complessiva del documento WSDL che descrive lèinterfaccia di un web service e quindi illustrata dal seguente listato. 23

Capitolo 2 <wsdl:definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> <wsdl:types> definition of types... </wsdl:types> <wsdl:message> <wsdl:part /> </wsdl:message> <wsdl:porttype> <wsdl:operation> <wsdl:input /> <wsdl:output /> </wsdl:operation> </wsdl:porttype> <wsdl:binding> <wsdl:operation> <wsdl:input /> <wsdl:output /> </wsdl:operation> </wsdl:binding> <wsdl:service> <wsdl:port /> </wsdl:service> </wsdl:definitions> Listato 2.2 ù Scheletro di un documento WSDL. La parte di WSDL relativa invece allèimplementazione del servizio e costituita dalla sezione service che contiene al suo interno lèelemento port in cui viene specificato un indirizzo fisico (URI) al quale e presente lèimplementazione del servizio descritto. A conclusione di questa panoramica va detto che WSDL non ha ancora raggiunto il grado di maturitadi SOAP e che la versione 1.2 in corso di definizione da parte del W3C introduce alcune modifiche, fra le quali lèintroduzione del nuovo elemento servicetype. Tuttavia lèimpostazione di massima puo ormai dirsi consolidata. [10] [2] [11] 24

Capitolo 3 Progetto del Web Service EBroker: analisi concettuale e problematiche coinvolte 3.1 Introduzione Come illustrato nel capitolo 1, si vogliono esplorare le tecnologie dei web services attraverso un case study reale in grado di evidenziare gli sforzi necessari per dotare un componente legacy aziendale di unèinterfaccia web service. In questo percorso si cercheradi pervenire ad un pattern progettuale capace di definire i passi logici della realizzazione di una simile operazione, valutando le diverse alternative che si presentano al progettista a livello concettuale. Successivamente si passeraalla fase implementativa che dovrascontare il confronto con le particolaritadel linguaggio adottato per la codifica; si dovraaltresı procedere a valutare lèutilizzo di particolari strumenti automatici in grado di abbattere i costi e i tempi di sviluppo. 3.2 Design Patterns E opinione unanime che il fattore limitante nel ciclo di sviluppo del software e costituito dagli elevati costi di produzione, motivo per il quale si ricercano continuamente nuove metodologie e modelli di sviluppo in grado di ridurre tali costi. Dèaltronde gli stessi web services rappresentano un modello di sviluppo del software che si propone di contenere i costi grazie al riuso di componenti in piattaforme eterogenee e alla riduzione degli sforzi di integrazione. Rimandando alle conclusioni per una valutazione 25

Capitolo 3 ragionata su questa promessa ù si tratta infatti dellèaspetto principe che si vuole misurare con il presente lavoro ù va detto che la progettazione del software per componenti, che e prassi ormai ampiamente consolidata nellèambito dellèingegneria del software, costituisce il primo, fondamentale, passo per il riuso del software e quindi per lèabbattimento dei costi. Di recente una particolare enfasi e pero sorta su un altro aspetto della progettazione che conduce al concetto di pattern. Un pattern puo essere definito come un modello che descrive un problema ricorrente per il quale e possibile adottare una soluzione comprovata. Si tratta cioe di riconoscere che lo specifico problema afferisce ad una particolare classe di problemi per la quale e giastata sviluppata una soluzione efficace che puo essere quindi riutilizzata per il problema in questione, evitando cosı di produrre nuovi ed inutili sforzi. Lèadozione di pattern in fase progettazione conduce inoltre alla produzione di un sistema software piu chiaro, meglio strutturato, architetturalmente piu valido e quindi piu facilmente modificabile, estendibile e riutilizzabile. [12] 3.2.1 Pattern di progettazione per il case study Da queste considerazioni emerge lèopportunitadi ragionare sul case study che si vuole affrontare al fine di inquadrare il lavoro da svolgere in un pattern di progettazione gia noto. Ricordando che lo scopo da raggiungere e quello di rendere il componente EBroker accessibile ad altri sistemi software mediante lèadozione degli standard dei web services, si puo in effetti affermare che lèoperazione da compiere afferisce ad una classe di problemi comuni ben individuata dal pattern Adapter di cui la figura 3.1 ne fornisce una rappresentazione in UML. Il problema puo essere cosı enunciato: un Client utilizza un metodo interfacemethod() appartenete allèinterfaccia TargetIF; si dispone di una classe Adaptee in grado di compiere ù quanto meno in massima parte ù le operazioni svolte dal metodo interfacemethod(), tuttavia essa non puo implementare lèinterfaccia TargetIF, o perch non si dispone dei sorgenti, o perch difformitasintattiche e semantiche degli argomenti lo impediscono. La soluzione proposta prevede lo sviluppo di unèaltra classe, Adapter, che 26