A mio nonno
Indice
1 Introduzione ... 7
2 Lo stato dell’arte ... 8
2.1
Le architetture orientate ai servizi ... 9
2.1.1
I servizi ... 10
2.1.2
Funzionamento ... 11
2.1.3
Campi d’applicazione ... 12
2.1.4
Considerazioni finali ... 14
2.2
I Web Service ... 15
2.2.1
SOAP ... 16
2.2.1.1
Struttura di un messaggio SOAP ... 16
2.2.1.2
SOAP e allegati ... 18
2.2.2
WSDL ... 19
2.2.2.1
Struttura di un WSDL ... 19
2.2.2.2
Tipologia di un servizio ... 20
2.2.3
UDDI ... 22
2.2.3.1
Struttura registro UDDI ... 22
2.2.4
Modello di funzionamento ... 24
2.2.5
Considerazioni finali ... 26
3 Un caso di studio: Poste Italiane ... 28
3.1
Background, scope ed obiettivi ... 28
3.2
Analisi As-‐Is ... 29
3.2.1
Architettura As-‐Is ... 30
3.2.2
Macro processo ... 31
3.2.3
Accesso al portale ... 33
3.2.4
OdA ... 34
3.2.4.1
Struttura file OdA ... 35
3.2.5
OdV ... 36
3.2.5.1
Struttura file OdV ... 39
3.2.6
Allineamento ... 41
3.2.7
Consegna e rientro ... 43
3.2.9
Gestione documentazione ... 45
3.2.10
Dettaglio dei dati inerenti ai processi ... 47
3.3
Considerazioni finali ... 51
4 Progettazione architettura To-‐Be ... 52
4.1
Raccolta requisiti ... 52
4.1.1
Obiettivi business ... 52
4.1.2
Obiettivi tecnici ... 53
4.1.3
Requisiti funzionali ... 53
4.2
Architettura To-‐Be ... 58
4.2.1
Architettura generale ... 60
4.2.2
Architettura applicativa ... 63
4.2.2.1
Presentation Layer ... 63
4.2.2.2
Business Layer ... 64
4.2.2.3
Persistence Layer ... 64
4.2.3
Architettura esecutiva ... 66
4.3
Considerazioni finali ... 68
5 Simulazione WFM ... 70
5.1Casi d’uso ... 71
5.2
Diagramma dei componenti ... 74
5.3
Diagramma delle classi ... 75
5.3.1
WFM ... 75
5.3.2
ClientPTI ... 76
5.3.3
GA ... 77
5.3.4
ClientExt ... 77
5.4
Modello dei dati ... 78
5.5
Diagramma di sequenza ... 80
5.6
Esempio di esecuzione ... 85
6 Conclusioni e sviluppi futuri ... 90
7 Bibliografia ... 94
Indice delle figure
Figura 1: Sistema SOA ________________________________________________________________ 11 Figura 2: Esempio di scenario SOA _______________________________________________________ 12 Figura 3: Grid computing ______________________________________________________________ 13 Figura 4: Web Service Stack ____________________________________________________________ 16 Figura 5: Struttura messaggio SOAP _____________________________________________________ 17 Figura 6: SOAP Request _______________________________________________________________ 18 Figura 7: SOAP Response ______________________________________________________________ 18 Figura 8: Esempio di documento WSDL per un Web Service ___________________________________ 20 Figura 9: Struttura del registro UDDI _____________________________________________________ 23 Figura 10: Architettura SOA con Web Service ______________________________________________ 24 Figura 11: Web Service in una rete aziendale ______________________________________________ 26 Figura 12: Web Service in un'architettura SOA _____________________________________________ 27 Figura 13: Architettura di riferimento ____________________________________________________ 30 Figura 14: Macro processo _____________________________________________________________ 31 Figura 15: Accesso al portale ___________________________________________________________ 33 Figura 16: Maschera OdA ______________________________________________________________ 34 Figura 17: Processo OdA _______________________________________________________________ 34 Figura 18: Maschera OdV ______________________________________________________________ 36 Figura 19: Processo OdV -‐ Packaging interno -‐ _____________________________________________ 37 Figura 20: Processo OdV -‐ Packaging esterno -‐ _____________________________________________ 38 Figura 21: Allineamento _______________________________________________________________ 41 Figura 22: Consegna e Rientro __________________________________________________________ 43 Figura 23: Appuntamenti ______________________________________________________________ 44 Figura 24: Gestione documentazione _____________________________________________________ 45 Figura 25: Maschera controllo documenti _________________________________________________ 46 Figura 26: Maschera validazione documenti “Ok” __________________________________________ 46 Figura 27: Maschera validazione documenti “Ko” ___________________________________________ 47 Figura 28: Architettura WFM-‐Configuratore _______________________________________________ 59 Figura 29: Architettura To-‐Be ___________________________________________________________ 60 Figura 30: Cambiamenti nell’architettura To-‐Be ____________________________________________ 61 Figura 31: Esempio processo To-‐Be ______________________________________________________ 62 Figura 32: Architettura applicativa ______________________________________________________ 63 Figura 33: Diagramma deployment ______________________________________________________ 65
Figura 34: Architettura esecutiva ________________________________________________________ 66 Figura 35: Scenario utilizzo WFM e Configuratore __________________________________________ 68 Figura 36: Diagramma casi d'uso ________________________________________________________ 71 Figura 37: Diagramma dei Componenti ___________________________________________________ 74 Figura 38: Diagramma delle Classi "wfm" _________________________________________________ 75 Figura 39: Diagramma delle classi "ClientPTI" ______________________________________________ 76 Figura 40: Diagramma delle classi "ga" ___________________________________________________ 77 Figura 41: Diagramma delle classi "ClientExt" ______________________________________________ 77 Figura 42: Modello E/R database "PTI" ___________________________________________________ 78 Figura 43: Diagramma di sequenza ______________________________________________________ 80 Figura 44: Esempio di struttura interna per GA _____________________________________________ 83 Figura 45: Esempio di struttura interna per OdA ____________________________________________ 83 Figura 46: Esempio di struttura interna per OdV ____________________________________________ 84 Figura 47: Registrazione Cliente Esterno __________________________________________________ 85 Figura 48: Richiesta file da elaborare ____________________________________________________ 85 Figura 49: Mappatura file .xsd __________________________________________________________ 86 Figura 50: Non disponibilità file .xsd _____________________________________________________ 86 Figura 51: Errori in mappatura del file ____________________________________________________ 87 Figura 52: Mappatura avvenuta ________________________________________________________ 87 Figura 53: Scelta funzionalità ___________________________________________________________ 88 Figura 54: Accesso al servizio respinto ____________________________________________________ 88 Figura 55: Elaborazione degli appuntamenti _______________________________________________ 89 Figura 56: Verifica documentazione _____________________________________________________ 89 Figura 57: Architettura con nuovi sviluppi _________________________________________________ 92 Figura 58: Benefici futuri ______________________________________________________________ 93
Indice delle tabelle
Tabella 1: Attori coinvolti nei processi ____________________________________________________ 29 Tabella 2: Header file OdA _____________________________________________________________ 36 Tabella 3: Body file OdA _______________________________________________________________ 36 Tabella 4: Header file OdV _____________________________________________________________ 39 Tabella 5: Body file OdV _______________________________________________________________ 40 Tabella 6: Informazioni scambiate nel processo OdA ________________________________________ 48 Tabella 7: Informazioni scambiate nel processo OdV ________________________________________ 50 Tabella 8: Informazioni scambiate nel processo Gestione documentazione _______________________ 50 Tabella 9: Stack software WFM _________________________________________________________ 67 Tabella 10: Benefici ottenibili ___________________________________________________________ 69 Tabella 11: Attori coinvolti _____________________________________________________________ 71 Tabella 12: Caso d'uso "Registrazione" ___________________________________________________ 72 Tabella 13: Caso d'uso "Accesso" ________________________________________________________ 72 Tabella 14: Caso d'uso "Gestione Flussi" __________________________________________________ 73 Tabella 15: Caso d'uso "Gestione Appuntamenti" ___________________________________________ 73 Tabella 16: Attributi tabella “Tags” ______________________________________________________ 79 Tabella 17: Attributi tabella “Clienti” _____________________________________________________ 79
Introduzione 1
1 Introduzione
Le attuali condizioni economiche e i rapidi cambiamenti del mercato tecnologico globale richiedono alle imprese di adattarsi rapidamente, portando ad una contestuale necessità di aumentare la propria flessibilità. Dal punto di vista informatico, questi requisiti si traducono in una maggiore efficienza operativa raggiunta, ad esempio, tramite l’automazione dei processi, ma soprattutto grazie alle attività che puntano all’integrazione delle applicazioni aziendali in modo da garantire che più sistemi di business possano condividere processi e dati.
Tuttavia, l'integrazione di più sistemi può portare ad architetture complesse e fragili che possono essere molto costose. Alcuni degli obiettivi chiave che le organizzazioni IT devono affrontare in questo contesto sono:
• Riduzione dei tempi di commercializzazione delle nuove funzionalità. • Diminuzione dei costi di integrazione e complessità.
• Gestione del cambiamento tecnologico.
• Disponibilità e scalabilità della piattaforma software.
Questa tesi è volta a descrivere le necessità di superamento dei problemi d’integrazione tra aziende eterogenee. Nei vari capitoli verranno discusse queste problematiche partendo dall’inquadramento del problema prima di addentrarsi, nel capitolo 2, in aspetti più tecnici. Negli altri capitoli verrà presentato un caso di studio aziendale in cui si dimostra come la migrazione verso un’architettura più flessibile porti vantaggi all’azienda. In particolare, nel capitolo 3 viene analizzata la situazione esistente, nel capitolo 4 vengono definiti gli obiettivi da raggiungere e la proposta di una nuova architettura e nel capitolo 5 viene presentata una simulazione per far capire meglio, da un punto di vista implementativo, esempi dei servizi effettivamente offerti. Nel capitolo finale vengono analizzati i benefici ottenibili, ma soprattutto vengono anche indicate le aree di miglioramento dell’architettura progettata.
Lo stato dell’arte 2
2 Lo stato dell’arte
La necessità d’integrazione delle varie piattaforme software è divenuta indispensabile dal momento in cui ha preso piede il Web; la rete mette a disposizione un ottimo mezzo di comunicazione ai fini dell’integrazione dei vari sistemi e le prospettive di crescita ed evoluzione delle aziende sono molto interessanti.
Per questo è necessario che un’azienda miri ad evolversi continuamente riconsiderando periodicamente la propria organizzazione dal punto di vista della tecnologia utilizzata, eventualmente adottandone una nuova, ed anche a livello di struttura interna, fondendola in alcuni casi con quella di altre aziende.
L’impatto che potrebbe avere questa reingegnerizzazione spesso non è indolore, sia a livello finanziario, per l’acquisto del software, sia in termini di conoscenze sul sistema utilizzato, che dovranno essere riacquisite dai propri tecnici ed operatori.
In questo ambito entra in gioco l’EAI1, una filosofia di sviluppo di nuovi sistemi che mira all’integrazione delle strutture esistenti all’interno dell’azienda, senza che queste debbano essere sostituite o modificate pesantemente.
Prima della nascita dell’EAI, l’integrazione era una scelta molto più rischiosa per le aziende: esse avrebbero dovuto fare un accurato studio di fattibilità per valutare tempi, costi e rischi. In alcuni casi i risultati di tale studio potevano portare le compagnie a rinunciare all’integrazione; in altri invece, dopo aver deciso di intraprendere tale strada, il processo poteva impiegare anni per arrivare a conclusione o addirittura poteva interrompersi prima della completa realizzazione a causa della crescita imprevista dei costi.
L’approccio EAI permette di superare queste problematiche, definendo una metodologia per far comunicare fra loro applicazioni diverse senza doverle modificare ad hoc; il processo d’integrazione viene separato dalle specifiche applicazioni, che vengono messe in comunicazione attraverso lo scambio di messaggi. Tramite l’EAI non è garantito solamente il mezzo per il trasporto dei messaggi, ma anche il loro instradamento, filtraggio ed elaborazione nascondendo la diversità delle varie applicazioni e dei sistemi connessi. In questo modo permette di accedere ad ognuno di essi utilizzando sempre lo stesso modello di programmazione ed il medesimo formato di scambio di dati. L’EAI è quindi la soluzione ideale per ambienti eterogenei.
1EAI = Enterprise Application Integration.
Lo stato dell’arte 2
Ad oggi lo scenario è ulteriormente cambiato, infatti la frontiera dell’integrazione si è spostata dal cercare di interconnettere sistemi diversi appartenenti alla stessa organizzazione, al cercare di far comunicare piattaforme appartenenti ad aziende differenti. Sebbene l’EAI tenti di risolvere questo problema, le soluzioni proposte non sono però del tutto utilizzabili, in quanto il controllo dell’elaborazione non è più in mano a una singola azienda, ma a compagnie differenti.
Dalla necessità di trovare un procedimento standard per poter esporre un software sulla rete attraverso un’interfaccia comprensibile a tutte le organizzazioni che lo utilizzeranno, sono nati i Web Service e le architetture orientate ai servizi, SOA2.
Tramite questi nuovi concetti architetturali, la difficoltà incontrata dai progettisti non è più, quindi, la condivisione delle informazioni tra organizzazioni diverse, quanto il superamento delle proprie barriere mentali; spesso, infatti, la migrazione verso una nuova architettura viene messa da parte perché considerata come un costo anziché come un beneficio.
2.1 Le architetture orientate ai servizi
L’OASIS3 definisce il SOA in questo modo:
“un paradigma per l'organizzazione e l'utilizzazione delle risorse distribuite che possono essere sotto il controllo di domini di proprietà differenti. Fornisce un mezzo uniforme per offrire, scoprire, interagire ed usare le capacità di produrre gli effetti voluti consistentemente con presupposti e aspettative misurabili.” (OASIS)
Altri esperti del settore come Mike Rosen danno una visione più business al concetto di SOA:
“uno stile architetturale finalizzato alla costruzione di soluzioni enterprise basate su servizi.
Più specificatamente, SOA ha a che fare con la costruzione di servizi allineati con il business e che possono essere combinati in processi di business di altro livello e in soluzioni all’interno di un contesto enterprise”. (Rosen)
La filosofia di sviluppo SOA, quindi, prende campo dal momento in cui conviene realizzare sistemi già pensando all'integrazione piuttosto che adattarli volta per volta. Questa filosofia
2 SOA = Service Oriented Architecture.
3 OASIS = Organization for the Advancement of Structured Information Standards. E’ un consorzio no-‐profit che guida lo sviluppo, la convergenza e l'adozione di standard aperti per la società dell'informazione globale.
Lo stato dell’arte 2
punta a fornire una nuova strategia di sviluppo di sistemi orientati al B2B4 all’interno di un contesto eterogeneo e distribuito. Con questa nuova forma architetturale vengono garantiti i requisiti, essenziali nel mercato di oggi, di interoperabilità e riusabilità dei servizi offerti in modo da andare incontro alle esigenze delle varie organizzazioni.
2.1.1 I servizi
I componenti essenziali dell’architettura SOA sono i servizi; essi sono applicazioni, indipendenti tra loro, che mettono a disposizione singole funzionalità attraverso la rete. In questo modo le aziende possono modificarli più semplicemente e velocemente, combinarli, aggiungerne di nuovi ed utilizzarli in modo personalizzato; ciò è garantito dal fatto che l’intera architettura non è più vincolata ad una piattaforma specifica, ma viene considerata come un insieme di componenti disaccoppiati (loosely coupled) tra loro.
La filosofia SOA permette, quindi, di andare a progettare sistemi con l’ottica di fornire un insieme di funzionalità ad altre applicazioni attraverso un’interfaccia ben definita nella rete. Riassumendo, un servizio gode delle seguenti proprietà:
• Indipendenza “fisica”: il funzionamento non deve dipendere né dalla piattaforma, né dal sistema operativo e neanche dal linguaggio col quale viene programmata. • Indipendenza “logica”: i servizi devono essere debolmente accoppiati tra loro,
ovvero devono esistere poche dipendenze. In questo modo viene garantita maggior flessibilità e riusabilità.
• Pubblicazione: deve essere resa nota solo l’interfaccia del servizio (le funzionalità offerte) e non come viene realizzato. Questa deve essere pubblicata sulla rete in modo che tutti gli altri componenti possono accedervi. A complicare il tutto ci sono gli aspetti legati al controllo degli accessi al servizio, ovvero i messaggi che vengono scambiati e le operazioni che vengono eseguite; per questo, insieme all’interfaccia, vengono rese note anche le modalità di accesso agli stessi. Infine è importante sottolineare il fatto che tali funzionalità devono essere accessibili in modo trasparente rispetto alla loro allocazione.
Lo stato dell’arte 2
• Scalabilità: i servizi devono essere realizzati in modo tale da permetterne la composizione con altri al fine di creare applicazioni più complesse. Questa proprietà, nota anche come “orchestrazione dei servizi”, viene raggiunta sfruttando dei linguaggi specializzati come, ad esempio, BPEL5.
Figura 1: Sistema SOA
2.1.2 Funzionamento
L’architettura SOA comprende tre attori principali:
1. Fornitore (Service Provider): entità che mette a disposizione il servizio. 2. Consumatore (Service Consumer): entità che utilizza il servizio.
3. Service Registry: entità in cui vengono memorizzate informazioni sul servizio come, ad esempio, l’URL6, le modalità di accesso, etc.
5 BPEL = Business Process Execution Language. 6 URL = Uniform Resource Locator.
Lo stato dell’arte 2
Un servizio è implementato da un Service Provider che lo espone verso uno o più Service Consumer attraverso un’interfaccia. I consumatori possono essere sia applicazioni interne, come processi di business o portali Web, sia entità esterne all’organizzazione. Attraverso un “contratto” vengono definite le strutture delle interfacce, le policy di sicurezza, ma anche aspetti non funzionali come la disponibilità e la latenza del servizio; questo contratto viene aggiornato, ma comunque mantenuto, anche quando vengono modificate le funzionalità. Il consumatore può ricercare ed accedere al componente offerto in rete tramite meccanismi di naming; le informazioni utili per effettuare questi controlli sono memorizzate nel Service Registry.
In Figura 2 viene mostrato un tipico scenario delle applicazioni in ottica SOA.
Figura 2: Esempio di scenario SOA
2.1.3 Campi d’applicazione
Le architetture SOA trovano la loro reale applicazione, ad esempio, in concetti ormai non più emergenti come il grid computing e l’on-‐demand computing.
I grid computing, o sistemi grid, sono un’infrastruttura di calcolo distribuito, utilizzati per l’elaborazione di grandi quantità di dati utilizzando una vasta quantità di risorse. Esistenti ormai da metà degli anni novanta (grazie all’affermazione delle reti di calcolatori e di
Lo stato dell’arte 2
Internet), questi sistemi centrano il loro funzionamento sulla condivisione coordinata di risorse all’interno di una dinamica organizzazione virtuale. Per risorse s’intendono sia computer, sia software o più in generale qualsiasi hardware che permetta la risoluzione di problemi ingegneristici e scientifici. A differenza del Web non mira a condividere informazioni, ma punta a creare una rete di computer che possa aumentare la potenza di calcolo; infatti, la caratteristica comune dei progetti grid è la necessità di disporre di un ambiente di calcolo all’interno del quale le applicazioni hanno il bisogno di accedere a grandi quantità di dati, geograficamente distribuiti, in maniera veloce e affidabile. È facile osservare che nessun computer attualmente in commercio sarebbe in grado, da solo, di elaborare simili moli di dati in tempi ragionevoli; ecco che l’architettura SOA porta vantaggi in tal senso offrendo soluzioni più flessibili che permettono maggiori prestazioni.
Ad oggi, la più importante grid europea è quella del CERN7 di Ginevra.
Figura 3: Grid computing
Anche l’on-‐demand computing non un concetto così nuovo dato che già John Mc Carthy nel 1961 disse:
“If computers of the kind I have advocated become the computers of the future, then computing may someday be organized as a public utility just as the telephone system is a public utility... The computer utility could become the basis of a new and important industry.” (Carthy)
7 CERN = Centro Europeo di Ricerca Nucleare. E’ il più grande laboratorio al mondo di fisica delle particelle fondato nel 1954.
Lo stato dell’arte 2
A metà degli anni novanta anche le grandi aziende sono tornate sul concetto di on-‐demand computing; con esso s’intende, infatti, la possibilità di gestire l’infrastruttura IT aziendale come se fosse un servizio interno, analogo all’erogazione di energia elettrica o impianti di telefonia. L’obiettivo è di allocare dinamicamente le risorse elaborative necessarie a soddisfare i fabbisogni presenti e futuri; si tratta di un modello in cui viene utilizzato solo ciò che effettivamente serve. Nel caso in cui si presentano malfunzionamenti, si possono riallocare le risorse per far fronte al fabbisogno richiesto dovuto indifferentemente sia da un picco di richiesta sia dalla mancata disponibilità di un nodo.
Anche in questo caso è facile intuire come i principi SOA possono fondersi bene con tali idee.
2.1.4 Considerazioni finali
Ponendosi nuove ed ambiziose sfide prestazionali, i team IT devono tenere comunque sotto controllo i flussi dei propri processi al fine di poterne analizzare le vere performance e di poterne capire e risolvere rapidamente eventuali errori. Per garantire, quindi, le maggiori prestazioni promesse è necessario che vengano rispettati tali requisiti:
• Monitoraggio del tempo di reazione end-‐to-‐end (di tutto il processo) delle varie operazioni.
• Profonda conoscenza delle performance dei servizi (cause delle scarse prestazioni e impatto dei servizi carenti sulle applicazioni).
• Capacità di mappare tutte le varie funzionalità e le associate dipendenze con il livello di granularità minimo necessario (singole operazioni).
• Definire parametri precisi (KPI8) secondo cui valutare in tempo reale, 24 ore su 24, 7 giorni su 7, le prestazioni; in questo modo è possibile anche dare notifica anticipata di possibili rallentamenti o blocchi di servizi.
Con questi requisiti i team possono considerarsi pienamente sotto controllo delle attività
complesse e composte su cui lavorano quotidianamente.
8 KPI = Key Performance Indicator.
Lo stato dell’arte 2
2.2 I Web Service
Per il W3C9:
“A Web service is a software system identified by a URI, whose public interfaces and
bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by internet protocols (HTTP)”. (W3C, 2002)
In altre parole tali sistemi software sono applicazioni web che cooperano tra loro, indipendentemente dalla piattaforma sulla quale si trovano, attraverso lo scambio di messaggi; essi sono progettati per supportare l’interoperabilità all’interno di contesti distribuiti.
Date le tante analogie concettuali con le architetture SOA, è intuitivo capire che fondendo i due principi è possibile ottenere un maggior supporto all’integrazione e maggiori prestazioni delle piattaforme aziendali.
Vediamo adesso i Web Service più da vicino, descrivendo in dettaglio le tecnologie da cui sono costituiti. Esse si basano su XML10, un linguaggio di markup, derivato da SGML11, utilizzato per la memorizzazione d’informazione in maniera strutturata. XML è un formato indipendente dalle varie piattaforme; ciò è dovuto, oltre che all’essere universalmente riconosciuto come standard, anche al fatto che tale tecnologia si basa sul formato testuale e quindi un può essere interpretato chiaramente su qualsiasi sistema operativo. Questa indipendenza lo rende la soluzione ideale per lo scambio d’informazioni attraverso il Web. Le tecnologie su cui si basano i Web Service sono:
• SOAP (Simple Object Access Protocol) • WSDL (Web Service Descripton Language)
• UDDI (Universal Description Discovery and Integration)
Essi sono protocolli di livello applicazione dello stack TCP/IP, come mostrato in Figura 4, per cui viene dato per scontato quello che si trova del livello Network in poi.
9 W3C = World Wide Web Consortium. E’ un'organizzazione non governativa internazionale fondata nel 1984 da Tim Berners-‐Lee che ha come scopo quello di sviluppare tutte le potenzialità del World Wide Web.
10 XML = eXtensible Markup Language.
Lo stato dell’arte 2
Figura 4: Web Service Stack
2.2.1 SOAP
SOAP è un protocollo di trasmissione di messaggi in formato XML. Esso mette a disposizione un meccanismo semplice, ma allo stesso tempo solido, che permette ad una applicazione di mandare un messaggio XML ad un’altra applicazione. Un messaggio è costituito da una trasmissione, dal mittente al ricevente, che può contenere uno o più messaggi (input/output); questi definiscono il tipo di comunicazione che stiamo stabilendo: One-‐way, Request-‐response, Solicit-‐response, Notification.
2.2.1.1 Struttura di un messaggio SOAP
Un messaggio SOAP è costituito da un contenitore, chiamato “Envelope”, all’interno del quale vengono distinte due sezioni principali denominate “Header” e “Body”, che contengono rispettivamente l’intestazione ed il corpo del messaggio.
La rappresentazione grafica di Figura 5 aiuta a comprendere meglio la struttura appena descritta.
Lo stato dell’arte 2
Figura 5: Struttura messaggio SOAP
•
Envelope: elemento obbligatorio che identifica il documento XML come un messaggio SOAP.•
Header: elemento opzionale che contiene informazioni dirette ai nodi intermediari, riguardanti l’instradamento del messaggio sulla rete; in questi blocchi sono contenute anche le informazioni sulla sicurezza (crittografia, autenticazione, firma,…)•
Body: elemento obbligatorio che contiene informazioni sulla chiamata e sulla risposta. E’ strutturato secondo il formato XML e può contenere sia semplici dati che chiamate a procedure (RPC).•
Fault: elemento opzionale che fornisce informazioni sugli eventuali errori che potrebbero verificarsi in fase di processo dei messaggi.Vediamo ora un semplice esempio di comunicazione SOAP tra un Web Service e un suo consumer. Il servizio possiede operazioni per la ricerca (per id, per nome, per range di date) e per la rimozione di uno sport. Assumendo che sia ben noto l'URL del servizio, l'applicazione client che vuole effettuare ricercare o rimuovere uno sport (fornendo i parametri corretti) può invocare l'operazione remota inviando un messaggio SOAP; la Figura 6 e la Figura 7 mostrano lo scambio di messaggi tra i due attori.
Lo stato dell’arte 2
Figura 6: SOAP Request
Figura 7: SOAP Response
2.2.1.2 SOAP e allegati
E’ possibile avere la necessità di inviare allegati di qualsiasi genere (mp3, jpg, mpg,…), rappresentati come dati binari nel calcolatore. Ad esempio, quando dobbiamo inviare un file binario, viene effettuata una doppia conversione dei dati binari (codifica/decodifica Base64), in invio e ricezione, per poter essere trasportati all’interno di un messaggio SOAP. Questa comporta una perdita di tempo e così sono nate soluzioni in cui i dati relativi agli allegati rimangono separati dal messaggio SOAP; ad esempio sono utilizzati pacchetti XOP12
o MIME13.
12 XOP = Xml binary Optimization Package. 13 MIME = Multipurpose Internet Mail Extension.
Lo stato dell’arte 2
2.2.2 WSDL
WSDL è un linguaggio basato su XML utilizzato per descrivere in modo completo un servizio web. Questo file descrive un servizio per “cosa fa”, “cosa comunica” e “dove si trova” in modo tale da fornire tutti i dettagli necessari per permettere una corretta invocazione dello stesso.
Esistono due versioni di tale linguaggio (WSDL 1.0 e WSDL 2.0), diverse solo per terminologia e per struttura, ma non per i concetti che esprimono.
2.2.2.1 Struttura di un WSDL
Un documento WSDL utilizza un insieme di definizioni. Esso inizia sempre con un elemento radice “definitions” ed al suo interno utilizza i seguenti costrutti:
• Types: racchiude le definizioni dei tipi dei dati che sono coinvolti nello scambio dei messaggi. Come sistema standard per la tipizzazione, WSDL si basa su quello definito per gli schemi XML (XSD14), ma allo stesso tempo è possibile aggiungere anche altri tipi.
• Message: definisce l’input e l’output dei servizi. Ogni elemento “message” racchiude le informazioni sui parametri relativi ad uno specifico messaggio.
• Port type: riporta dettagli relativi alle operazioni che un Web Service rende disponibili. Ogni operazione viene descritta facendo uso di un ulteriore elemento chiamato “operation”. Al suo interno vi sono i messaggi di input e/o di output accettati dal servizio e l’ordine che è necessario seguire per il passaggio dei parametri. Tali messaggi vengono identificati rispettivamente dagli omonimi elementi; la presenza di uno o entrambi di essi e l’ordine in cui vengono riportati determinano la tipologia del servizio. Può essere presente anche l’elemento “fault” che specifica il formato del messaggio per ogni errore che può essere restituito in output dall’operazione.
• Binding: descrive il modo in cui avviene la comunicazione con il servizio. Qui viene stabilito il legame di ogni funzionalità del Web Service con il protocollo per lo scambio di messaggi, ad esempio, HTTP. In particolare si specifica il protocollo per
14 XSD = XML Schema Definition.
Lo stato dell’arte 2
ognuno dei messaggi di un servizio; solitamente viene scelto HTTP(s) come protocollo di trasporto per i messaggi SOAP.
• Service: è la sezione relativa alla localizzazione del Web Service. Al suo interno si trova l’elenco di tutti i servizi messi a disposizione; ognuno di essi è definito da un indirizzo URL, chiamato anche endpoint, al quale può essere trovato il Web Service.
I primi tre punti descrivono il servizio in un modo più astratto, mentre gli ultimi due descrivono concretamente come e dove vengono trasportati.
Di seguito viene riportato un esempio di documento WSDL 2.0, relativo ad un Web Service per un’agenzia di scommesse.
Figura 8: Esempio di documento WSDL per un Web Service
2.2.2.2 Tipologia di un servizio
Abbiamo accennato poco sopra, nella sezione relativa a “portType”, che i servizi possono appartenere ad una tipologia piuttosto che ad un’altra, in relazione alla presenza e all’ordine degli elementi input ed output. Le tipologie a cui un servizio può appartenere sono quattro:
•
One-‐way: è presente il solo elemento input. Come intuibile dal nome, la comunicazione avviene in una sola direzione ed in modo asincrono: viene inviato un messaggio da un client al servizio, dopodiché il primo continua la sua computazione senza attendere una risposta dal secondo.•
Request-‐response: sono presenti entrambi gli elementi input ed output, in questo ordine. Il servizio riceve il messaggio di richiesta dal client e, dopo aver eseguito l’elaborazione relativa, manda indietro un messaggio di risposta (sincrono).Lo stato dell’arte 2
•
Solicit-‐response: vi sono entrambi gli elementi ma in ordine inverso. E’ il servizio ad iniziare la comunicazione inviando un messaggio al client ed attendendo poi una sua risposta.• Notification: è il caso opposto del One-‐way. Il servizio spedisce un messaggio al client senza attendere una sua risposta. E ́ quindi presente solo l’elemento output.
Ognuna di queste tipologie individua la natura del servizio che stiamo descrivendo. Ad esempio, la tipologia Request-‐response è quella utilizzata nel modello di comunicazione RPC15, mentre si può avere il caso One-‐way quando sia presente un servizio che
memorizza dati ricevuti da più client, senza restituire un messaggio di risposta.
15 RPC = Remote Procedure Call.
Lo stato dell’arte 2
2.2.3 UDDI
E’ una metodologia standard per la pubblicazione e la rintracciabilità di un servizio in un’architettura SOA. I fornitori dei servizi UDDI (IBM, Microsoft, SAP, …) gestiscono un registro
basato su XML e che utilizza SOAP per le comunicazioni da e verso l’esterno; si può accedere a questo registro per:
•
Pubblicare servizi che un’azienda rende disponibili.•
Cercare aziende che mettono a disposizione un certo tipo di servizio.•
Avere informazioni, comprensibili all’utente, relativi ad un’azienda come indirizzi, contatti o altro.•
Avere informazioni tecniche, interpretabili ed utilizzabili dalla macchina, relative ad un servizio in modo tale da potervisi connettere.Un registro UDDI è costituito da un database distribuito, cioè da molti registri distribuiti sulla rete, ognuno dei quali si trova sul server di un’azienda che contribuisce allo sviluppo di questo archivio pubblico, e connessi fra loro. L’informazione viene memorizzata su un nodo del sistema e poi, attraverso una sincronizzazione, viene resa disponibile a tutti gli altri. Questo, oltre che ad alleggerire il carico di lavoro che un singolo nodo deve sopportare, contribuisce alla protezione del sistema contro possibili situazioni critiche del database, grazie alla ridondanza dei dati.
Per semplicità consideriamo UDDI come un unico grande registro.
Riassumendo, UDDI è visto come un elenco telefonico, ed offre tre servizi:
• White Pages: permette di trovare informazioni di un servizio per nome (indirizzo, contatti,…).
• Yellow Pages: permette di trovare un servizio per categoria.
• Green Pages: fornisce informazioni tecniche sui servizi offerti da un’azienda.
2.2.3.1 Struttura registro UDDI
Il registro UDDI è composto da quattro parti principali, ognuna delle quali con scopi diversi:
• businessEntity: memorizza informazioni relative alle aziende che hanno pubblicato il Web Service, come, ad esempio, il nome, l’indirizzo e i contatti (White Pages). Ad ognuna di esse fanno riferimento una o più businessService.
Lo stato dell’arte 2
• businessService: memorizza informazioni descrittive di un particolare servizio come il nome e la categoria di appartenenza, (Yellow Pages).
• bindingTemplate: memorizza informazioni tecniche di un Web Service, come la localizzazione e le modalità di accesso (Green Pages). Mette in relazione un
businessService con la sua reale implementazione.
• tModel: memorizza informazioni tecniche che descrivono una particolare tecnologia di servizio, compresa la specifica della relativa interfaccia (Green Pages). Questo registro definisce la specifica di un certo tipo di servizio, precisando, ad esempio, l’interfaccia che esso deve o dovrà avere; infatti, non è indispensabile che un servizio sia implementato, ma è sufficiente che sia ideato in termini di specifiche. Esso memorizza l’URL del WSDL e successivamente, quando verrà implementato, il “bindingTemplate” si riferirà a uno o più “tModel”.
In Figura 9 viene schematizzato quanto detto precedentemente.
Lo stato dell’arte 2
2.2.4 Modello di funzionamento
DI seguito viene riportato il funzionamento di un’architettura SOA che fa uso della tecnologia dei Web Service.
Figura 10: Architettura SOA con Web Service
La Figura 10 evidenzia l’interazione che c’è tra i Service Provider, Service Consumer e UDDI Service. Sono raffigurati tre Web Service generici per indicare il fatto che in un’architettura SOA non esistono ruoli designati, ma tutti i servizi possono essere sia fornitori che consumatori; il ruolo è quindi stabilito dalle connessioni. In questo specifico esempio, il Web Service in alto a destro espone un servizio e gli altri due lo utilizzano.
Il Service Provider crea un servizio e pubblica la sua descrizione, il WSDL, su UDDI. In questo modo gli altri Web Service, i Service Consumer, vanno a ricercare il servizio interrogando il registro UDDI; una volta ottenuto il file WSDL, essi effettuano il binding del servizio (si collegano al server del fornitore) ed iniziano ad invocare le operazioni messe a disposizione utilizzando le giuste convenzioni (nome metodo, parametri, …). Lo scambio di messaggi avviene col protocollo SOAP in modo tale che siano comprensibili sia al fornitore che al consumatore.
Le operazioni possibili sono quindi tre:
• Publish: pubblicazione della descrizione del servizio effettuata dal fornitore del servizio.
Lo stato dell’arte 2
•
Inquiry: ricerca della descrizione dell’interfaccia del servizio da utilizzare. Inoltre, sempre in questa fase, viene effettuato il binding del servizio usando le informazioni trovate nel WSDL.•
Comunication: scambio di messaggi tra i Web Service attraverso le specifiche del protocollo SOAP.Ad oggi, però, si riscontra come il meccanismo UDDI non sia molto utilizzato e la ricerca e pubblicazione dei servizi viene fatta secondo una procedura “manuale”, ovvero saranno direttamente le aziende che lo cercano nel web, tramite passaparola o altri meccanismi alternativi.
Analizzando il modello di funzionamento dei Web Service (Figura 10) e quello SOA (Figura 2) si può affermare che i due principi si sposano molto bene insieme; entrambi, infatti, offrono:
•
Indipendenza dalla piattaforma: i Web Services possono comunicare fra loro anche se si trovano su piattaforme differenti.•
Indipendenza dall’implementazione: l’interfaccia che un Web Service presenta sulla rete è indipendente dal software che implementa tale servizio. In questo modo potrà essere cambiata, migliorata o sostituita senza che l’interfaccia subisca modifiche.•
Riuso dell’infrastruttura: per lo scambio di messaggi si utilizza SOAP che fa uso di HTTP, grazie al quale si ottiene anche il vantaggio di permettere ai messaggi di passare attraverso i firewall.•
Riuso del software: è possibile riutilizzare software implementatoprecedentemente e renderlo disponibile attraverso la rete.
Quindi, sfruttando al meglio tutte le caratteristiche della tecnologia dei Web Services, si può implementare un sistema con architettura orientata ai servizi su larga scala, ovvero su
Lo stato dell’arte 2
2.2.5 Considerazioni finali
In questo paragrafo viene spiegato come parlare di Web Service non implica necessariamente parlare di architettura SOA. Ad esempio, uno scenario che evidenzia questo può essere quello in cui in una rete interna ad un’azienda vengono realizzate applicazioni basate sui Web Service; se si prevede che le modifiche da apportare al sistema non siano così frequenti nel tempo, è possibile memorizzare le informazioni di ognuno dei servizi nei file di configurazione.
Questo significa che il consumatore conosce già l’URL a cui trovare il servizio reso disponibile dal fornitore; vengono, perciò, utilizzati dei riferimenti statici per accedere ai vari servizi.
Figura 11: Web Service in una rete aziendale
Viene di seguito descritto un secondo caso in cui i Web Service sono utilizzati all’interno di un’architettura a servizi al fine di integrare applicazioni di più aziende o di filiali diverse della stessa organizzazione. In questo scenario vengono utilizzati i servizi Web per garantire che due aziende partner possono mettere a disposizione funzionalità a vicenda, senza preoccuparsi degli aspetti di compatibilità tra piattaforme, tra linguaggi di programmazioni e tra sistemi operativi.
Lo stato dell’arte 2
Figura 12: Web Service in un'architettura SOA
L’esempio mostra quanto descritto precedentemente; infatti vengono integrati Web Service realizzati su due piattaforme diverse, J2EE16 e .NET17. A differenza dell’esempio in Figura 11, non si conoscono gli URL al momento dell’implementazione dei servizi, per cui è necessario che il Service Registry fornisca gli indirizzi ed altre utili informazioni a tempo di esecuzione.
16J2EE = Java 2 Platform Enterprise Edition. 17.NET = Microsoft .NET.
