Università della Calabria

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Università della Calabria"

Transcript

1 Università della Calabria Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica Dipartimento DEIS TESI DI LAUREA Sviluppo di un sistema per la configurazione della rete UTRAN tramite un Enterprise Service Bus Open Source RELATORE Prof. Sergio FLESCA CO-RELATORE Dott. Ciro ROMANO CANDIDATO Francescantonio ALBANESE

2 Indice Introduzione 4 Capitolo 1: Enterprise Application Integration L importanza di integrare Enterprise Application Integration Dall'Enterprise Integration alle architetture orientate ai servizi 15 Capitolo 2: Service-Oriented Architecture e Web Services: concetti base Service-Oriented Architecture (SOA) Caratteristiche di una Service-Oriented Architecture Come funziona una Service-Oriented Architecture I Web Services Web Services e architettura di tipo non SOA Web Services e architettura SOA 35 Albanese Francescantonio, Pagina 1

3 Capitolo 3: Service-Oriented Architecture e gli Enterprise Service Bus Enterprise Service Bus come infrastruttura di supporto ad architetture Service-Oriented Perché Enterprise Service Bus? Enterprise Service Bus: Funzionalità supportate 48 Capitolo 4: Una piattaforma di integrazione applicativa Perché GreenVulcanoESB? Componenti Base e Architettura di GreenVulcanoESB Il Virtual Layer Il Core Integration Suite Connectivity Layer Amministrazione e controllo del sistema VulCon DataHandler UDDI I Vantaggi dell'utilizzo di GreenVulcanoESB 61 Albanese Francescantonio, Pagina 2

4 Capitolo 5: Configurazione di GreenVulcanoESB per la gestione della rete UTRAN L ambiente di lavoro Che cos è la rete UTRAN? La tecnologia UMTS Architettura di base del sistema UMTS Scenario del sistema Configurazione di GreenVulcanoESB 79 Testing 106 Conclusioni 114 Bibliografia 115 Albanese Francescantonio, Pagina 3

5 Introduzione Tra gli obbiettivi primari di ogni azienda c è quello di rimanere sempre a passo con i tempi, seguendo l evoluzione tecnologica, in modo da poter offrire ai propri clienti nuovi servizi a prezzi competitivi. Ogni azienda pertanto ha la necessità di evolversi continuamente, riorganizzandosi periodicamente sia in termini di tecnologia utilizzata, eventualmente adottandone delle nuove, sia della propria struttura interna, fondendola in alcuni casi con quella di altre aziende evitando, allo stesso tempo, di perdere investimenti passati. Risulta indispensabile, quindi, per un azienda, costruire un sistema informativo che sia capace di assorbire in maniera flessibile gli impatti delle nuove tecnologie salvaguardando il patrimonio informativo esistente. Vediamo quindi che il modo migliore per fornire nuovi servizi senza cambiare le basi del corebusiness delle compagnie è l integrazione dei vecchi sistemi con quelli nuovi. La necessità di integrare nasce in maniera naturale nell evoluzione dei sistemi. Lo scopo principale di questa attività è di riuscire ad integrare sistemi informativi eterogenei e autonomi, in modo da sviluppare il business e mantenere stabilità a quanto già presente nell azienda. Con l obbiettivo di avere un integrazione ideale in cui i sistemi e gli applicativi di un azienda sono tutti interconnessi e i processi operativi semplificati, sono stati sviluppati software integrativi specializzati, noti come Albanese Francescantonio, Pagina 4

6 Enterprise Application Integration (EAI), che trasferiscono i dati da un sistema all altro e correlano i complessi processi operativi di un azienda ai sistemi informativi e al software in uso. I progetti EAI risultano però, di grandi dimensioni, complessi, non flessibili, costosi per l elevatissima tassa di licenza software e molti di essi non sono in grado di rispettare tempi e budget. Con l avvento del Web, ambiente eterogeneo per eccellenza, e lo sviluppo di standard che descrivono come i sistemi informatici debbano comunicare, il software EAI è progettato e sviluppato in modo da utilizzare questi ultimi con una netta riduzione dei costi di sviluppo e manutenzione. Nasce la necessità di avere un modo standard per esporre un software su una rete attraverso un interfaccia comprensibile da tutte quelle aziende che, volendo far interagire le proprie applicazioni con quelle di altre compagnie, riconoscono tale standard, così, si assiste alla definizione di una serie di best-practices indicate con il termine Service-Oriented Architecture (SOA, Architettura Orientata ai Servizi) e all introduzione dei Web Services. Queste nuove tecnologie hanno guadagnato l attenzione dei leader dell Information Technology, dei venditori e degli analisti. L Enterprise Service Bus (ESB) racchiude le caratteristiche migliori di queste tecnologie. Un ESB è generalmente progettato per permettere che applicazioni di diverso tipo si scambino messaggi con lo scopo di estendere le funzionalità di ciascuna applicazione con quelle fornite dalle altre applicazioni e di rendere virtuali le risorse aziendali, permettendo alla logica di business dell azienda Albanese Francescantonio, Pagina 5

7 di essere sviluppata e gestita indipendentemente dall infrastruttura della rete. Le applicazioni che si collegano all ESB, possono inserire documenti aziendali, quali fatture, andamento titoli o transizioni commerciali. Tali documenti, viaggiano attraverso il bus da un applicativo all altro e vengono tradotti e trasformati in modo che ciascun applicativo veda il documento in un formato e in una struttura comprensibile. L ESB consente un integrazione su vastissima scala. A differenza delle tradizionali soluzioni EAI, che richiedono un significativo esborso iniziale, l ESB può essere utilizzato per connettere anche due soli sistemi aziendali in modo assolutamente economico. Gli altri sistemi possono essere aggiunti anche uno alla volta, permettendo alle aziende di mantenere il controllo sulle priorità, la portata e il costo dei rispettivi progetti. Quando viene collegato all ESB, ogni successivo sistema si rende disponibile a tutti gli altri sistemi collegati. Questo strumento risulta essere un rivoluzionario approccio all integrazione applicativa. Essendo una soluzione aperta e basata su standard, offre vantaggi fondamentali rispetto alla tradizionale EAI. Le aziende possono integrare i processi con sistemi terzi e interni, possono integrare applicativi legacy, non sono "vincolate" a un particolare fornitore, possono sviluppare e gestire una soluzione ESB senza doversi affidare a consulenti esterni e possono cominciare a sviluppare piccoli progetti integrativi da ampliare successivamente, riducendo i rischi e utilizzando i budget in modo più razionale. Il basso costo di sviluppo di questa tecnologia Albanese Francescantonio, Pagina 6

8 basata su standard si riflette in una tassa di licenza software inferiore rispetto alla EAI. Ad oggi, diverse compagnie di Information Technology hanno realizzato o intendono realizzare un proprio prodotto ESB da proporre sul mercato, lo scopo di questa tesi è quello di proporre l implementazione che è stata sviluppata nell azienda presso la quale ho svolto il tirocinio l Software, azienda operante nel campo dell'integrazione applicativa in ambito Enterprise, presentando poi un esempio di utilizzo dello strumento per mostrarne alcune funzionalità. La tesi è articolata nel modo seguente: Nel Capitolo 1 è affrontato il problema dell integrazione in ambito aziendale e l avvento delle nuove tecnologie che tentano un miglioramento del processo di integrazione, la SOA e i web services. Nel Capitolo 2 è stata fatta una panoramica sulle caratteristiche e sul funzionamento di una Service-Oriented Architecture e sui web services. Nel Capitolo 3 viene presentato l Enterprise Service Bus (ESB) come infrastruttura di supporto ad architetture Service-Oriented ed è messa in evidenza l importanza dell utilizzo di questo strumento come supporto alle aziende per incrementare la connettività ed aggiungere flessibilità per facilitare il cambiamento e avere un maggiore controllo sull utilizzo delle importanti risorse che unisce. Il Capitolo 4 è dedicato alla descrizione di GreenVulcanoESB, l Enterprise Service Bus prodotto dall azienda presso la quale ho svolto il tirocinio. Albanese Francescantonio, Pagina 7

9 Vengono descritti in particolare le componenti base dello strumento, l architettura e i vantaggi del suo utilizzo. La tesi si conclude con il Capitolo 5 in cui è descritto nei dettagli il lavoro svolto in azienda, in particolare, la configurazione del bus per sviluppare il sistema di gestione per la rete UTRAN. Albanese Francescantonio, Pagina 8

10 Capitolo 1 Enterprise Application Integration 1.1 L importanza di integrare Lo sviluppo dei sistemi informativi di un azienda non avviene in maniera continua e omogenea: spesso, l avvento di nuove tecnologie e i bisogni legati al business 1 producono ciclicamente la necessità di creare nuovo software. Quando questo accade, bisogna affrontare diverse problematiche sia dal punto di vista tecnologico che economico e organizzativo. L aspetto economico rappresenta per un azienda, con un sistema informativo complesso, uno dei punti primari da considerare, infatti, questa è consapevole che il cambiamento è inevitabile pertanto il suo principale obiettivo è gestirlo in modo tale da minimizzarne l impatto. Ciò significa evolversi conservando allo stesso tempo prodotti, tecnologie e applicazioni che già si possiedono. 1 Il termine inglese business identifica in generale un'attività economica. Approssimativamente può essere tradotto con il termine italiano affari. Albanese Francescantonio, Pagina 9

11 Tra le sollecitazioni che inducono all evoluzione del sistema informativo c è il business, che è in continuo e rapido cambiamento, la competizione, che diventa sempre maggiore e gli standard, che impongono alle aziende una sempre maggiore reattività e apertura del sistema informativo. Oltre a queste sollecitazioni esterne, ce ne possono essere altre, di varia natura, come ad esempio il raggiungimento di obiettivi legati alla ottimizzazione dei processi aziendali, oppure, la necessità di integrare applicazioni esistenti. L obiettivo delle aziende è di rispondere sempre più velocemente a queste continue sollecitazioni, costruendo un sistema informativo capace di assorbire in maniera flessibile gli impatti delle nuove tecnologie, salvaguardando il patrimonio informativo esistente. La necessità di effettuare attività di integrazione nasce, quindi, in maniera naturale nell evoluzione dei sistemi con lo scopo principale di riuscire ad integrare sistemi informativi eterogenei e autonomi, per sviluppare il business e mantenere stabilità a quanto già presente nell azienda. Nel corso degli anni, infatti, i sistemi informativi si sono evoluti in una stratificazione di prodotti, tecnologie e architetture eterogenee, data la presenza congiunta di soluzioni differenti, magari sviluppate in tempi e con prospettive differenti e ogni ambiente informatico risulta essere caratterizzato da un ampia eterogeneità e quindi, quasi inevitabilmente, da svariati problemi di interoperabilità e integrazione tra i diversi componenti. Albanese Francescantonio, Pagina 10

12 Con lo sviluppo della rete è diventato concreto il problema dell integrazione a livello business, cioè la creazione di processi Business to Business (B2B) 2 ottenuti componendo funzionalità esposte da organizzazioni differenti. Possiamo quindi parlare di integrazione interna, normalmente legata a una estensione dei sistemi con nuove o vecchie tecnologie e integrazione esterna. Il problema è, quindi, molto complesso e va affrontato da un punto di vista architetturale, pertanto è necessario fare una classificazione delle strategie architetturali che è possibile utilizzare per l integrazione. Possiamo supporre di avere un sistema informativo a layer ( strati ) che sia possibile suddividere in: Data Layer Business Layer Presentation Layer Le strategie di integrazione sono classificabili in base al layer su cui vanno ad agire. Possiamo quindi pensare di integrare a livello di presentazione (presentation), a livello di logica applicativa (business) oppure a livello di dati (data). 2 Business to Business (letteralmente "azienda-verso-azienda"), spesso indicato con l'acronimo B2B, è un termine comunemente utilizzato per descrivere le transazioni commerciali elettroniche tra imprese. Albanese Francescantonio, Pagina 11

13 La scelta del livello su cui effettuare l integrazione dipende da molti fattori e spesso non è consapevole, perché guidata da considerazioni più di natura tecnologica che architetturale (esempio tipico: bisogna utilizzare un determinato strumento e/o prodotto e/o tool. La classificazione che è possibile fare sulle strategie di integrazione è: 1. Portal Integration (PI) costruita a livello di interfaccia utente. Questo tipo di strategia è molto comune dato che è semplice da implementare, non è invasiva nei confronti delle applicazioni integrate e permette di effettuare in maniera semplice e rapida l aggregazione di sistemi molto eterogenei tra loro. Mentre l integrazione a livello di logica di business aggrega elaborazione di sistemi diversi, l integrazione a livello di portale visualizza in una singola finestra le informazioni provenienti da sorgenti multiple e differenti. Quello che viene realizzato è quindi un accorpamento di diverse applicazioni su un interfaccia comune. Ad esempio, è possibile pensare di integrare un applicazione di customer-care e un applicazione di gestione di dati bancari: l operatore può visualizzare sulla stessa schermata il conto corrente associato a un utente (sulla zona dedicata all applicazione di customercare) e effettuare delle operazioni sul conto corrente di questo utente sulla seconda applicazione (sull altra zona). Il portale diventa di fatto il punto centrale di accesso per un insieme eterogeneo di applicazioni. 2. Enterprise Information Integration (EII) è un approccio incentrato sull integrazione a livello dati. Si basa sul concetto che in alcune organizzazioni il problema è legato non tanto alla condivisione della logica, Albanese Francescantonio, Pagina 12

14 quanto ad avere una modalità di accesso ai dati centralizzata, omogenea e condivisa. In questo caso si ritiene che l integrazione a livello di logica applicativa non sia necessaria: l obiettivo è avere applicazioni che agiscono sugli stessi dati, che devono essere quindi accessibili in maniera omogenea. 3. Enterprise Application Integration (EAI) con questo termine si indicano tutte quelle strategie focalizzate sull integrazione della logica applicativa; lo scopo è la condivisione della business logic 3 tra applicazioni diverse o la composizione, in processi nuovi, di pezzi di logica già sviluppati. Al contrario della PI, dove sia i dati che la logica possono vivere indipendentemente, in questo caso parte della logica di business è necessariamente condivisa. È importante notare che i tre approcci descritti, Portal Integration (PI), Enterprise Application Integration (EAI) e Enterprise Information Integration (EII), non sono in assoluta alternativa ma possono essere complementari: l EII può ad esempio essere posta al servizio di soluzioni di portale fornendo ad esse un accesso unificato a diverse sorgenti dati, con una semplificazione nella costruzione delle soluzioni stesse. Per lo scopo di questa tesi, ci soffermeremo in maniera più dettagliata sull Enterprise Application Integration. 3 Business Logic è un termine che si riferisce a tutta quella logica applicativa che rende operativa un'applicazione. Il business logic racchiude in sé regole cosiddette di "business", piuttosto che regole ed elementi legati alla visualizzazione delle informazioni (vista o interfaccia grafica) o alla memorizzazione dei dati (es. database, ecc.). Albanese Francescantonio, Pagina 13

15 1.2 Enterprise Application Integration Possiamo classificare le strategie di integrazione EAI secondo vari approcci. Il primo approccio prevede la realizzazione di collegamenti peer-to-peer (P2P) 4 che permettano di avere connessioni dirette tra le applicazioni da integrare, ognuna delle quali può chiamare l'altra mediante specifiche Application Programming Interfaces (APIs) 5 e gestire singolarmente i problemi di comunicazione e di mapping dei dati. Il vantaggio principale dell approccio peer-to-peer è che in questo modo si crea una connessione stretta e sincrona tra le due applicazioni, con la possibilità di integrare all interno del codice non solo le necessarie conversioni dei dati, ma anche le regole di business. Lo svantaggio principale è che tale codice può essere complesso da sviluppare e va generato per ogni coppia di applicazioni. All aumentare delle applicazioni da integrare crescono anche le connessioni da implementare e l accoppiamento tra di esse, con evidenti impatti sui costi di sviluppo e soprattutto di manutenzione. Per evitare i problemi sopra descritti, è opportuno definire nell architettura uno strato centrale di integrazione che permetta di isolare le applicazioni gestendone le interconnessioni. Questo tipo di architettura può essere 4 Per peer-to-peer (o P2P) si intende una rete di computer o qualsiasi rete informatica che non possiede nodi gerarchizzati come client o server fissi (clienti e serventi), ma un numero di nodi equivalenti (pari, in inglese peer appunto) che fungono sia da cliente che da servente verso altri nodi della rete. 5 Le Application Programming Interface API (Interfaccia di Programmazione di un'applicazione), sono ogni insieme di procedure disponibili al programmatore, di solito raggruppate a formare un set di strumenti specifici per un determinato compito. Albanese Francescantonio, Pagina 14

16 realizzata tramite un approccio diretto (Server-Based), oppure tramite l utilizzo di un middleware 6 di appoggio. L approccio diretto (Server-Based), prevede di utilizzare una qualche tecnologia di connessione e comunicazione, demandando allo strato applicativo le ulteriori problematiche di integrazione. Con l approccio basato sull utilizzo di un middleware che agisce da intermediario, si definisce nell architettura uno specifico strato di integrazione che permette di centralizzare la gestione delle interconnessioni, evitando di affidare questo problema alle specifiche applicazioni. 1.3 Dall'Enterprise Integration alle architetture orientate ai servizi Con l avvento del Web, ambiente eterogeneo per eccellenza, i tradizionali approcci all integrazione di applicazioni non sono più utilizzabili. Questo è dovuto, oltre che all eterogeneità del campo di sviluppo, anche al fatto che il controllo dell elaborazione non è più in mano ad una singola azienda, dato che l interazione avviene tra applicazioni appartenenti a differenti compagnie. Vi è quindi la necessità di avere un modo standard per esporre un software su una rete attraverso un interfaccia comprensibile da tutte quelle aziende che, volendo far interagire le proprie applicazioni con quelle di 6 Con il termine middleware si intende un insieme di programmi informatici che fungono da intermediari tra diverse applicazioni. Sono utilizzati come supporto per applicazioni distribuite complesse. Albanese Francescantonio, Pagina 15

17 altre compagnie, riconoscono tale standard. Di conseguenza, per superare le limitazioni di middleware e piattaforme EAI, sono state definite una serie di best-practices che globalmente vengono indicate con il termine Service- Oriented Architecture (SOA, Architettura Orientata ai Servizi) e sono stati introdotti i Web Services. La Service-Oriented Architecture è un nuovo paradigma architetturale che risolve i problemi tradizionalmente legati all'integrazione, poiché nell'architettura che ne deriva, applicazioni software scritte in diversi linguaggi di programmazione e implementate su diverse piattaforme hardware possono interagire e scambiare informazioni e processi sotto forma di servizi indipendentemente dalle singole logiche di business che li generano. Essa pone delle specifiche condizioni che i componenti del sistema devono rispettare e le caratteristiche che tale sistema deve necessariamente avere. I Web Services sono invece una nuova tecnologia, che si basa su standard specifici, quali extensible Markup Language (XML), Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), Universal Description, Discovery and Integration (UDDI), di cui parleremo più avanti, la quale fornisce un facile metodo di interfacciamento tra le applicazioni. Questa tecnologia non è legata all architettura orientata ai servizi ma, ha molti punti di contatto con essa e i sistemi che utilizzano i Web Services, sfruttando tutte le loro potenzialità, implementano esattamente un architettura di tale tipo. Web Services e SOA cercano di fornire una Albanese Francescantonio, Pagina 16

18 soluzione al problema dell interoperabilità e le fondamenta per lo sviluppo di applicazioni distribuite su larga scala. Molti dei principi di SOA si sposano quindi alla perfezione con le problematiche di integrazione e discendono direttamente dalla consapevolezza che, se il sistema che si sviluppa ha successo, in futuro occorrerà estenderlo/integrarlo, oppure dal fatto che si ritiene necessario conservare gli asset 7 dell'organizzazione a fronte di una evoluzione tecnologica, in questo caso facendo esplicitamente integrazione. Fare integrazione con SOA significa cercare di trasformare le funzionalità già presenti in servizi. Questa evoluzione è indice di una maggiore maturità architetturale delle organizzazioni che si rendono conto dei costi che derivano da un errata applicazione dell'integrazione. 7 Gli Asset coincidono con il complesso di hardware, software conoscenze e abilità operative consolidate di proprietà dell'impresa. Albanese Francescantonio, Pagina 17

19 Capitolo 2 Service-Oriented Architecture e Web Services: concetti base 2.1 Service-Oriented Architecture Una Service-Oriented Architecture (SOA, Architettura Orientata ai Servizi) è un modello architetturale per la progettazione di sistemi residenti su una rete che focalizza l attenzione sul concetto di servizio. Il presupposto che guida la SOA è la considerazione che conviene sviluppare sistemi già pensando all'integrazione (il cambiamento è inevitabile) piuttosto che adattarli volta per volta. Un sistema costruito seguendo la filosofia SOA è costituito da applicazioni, chiamate servizi, ben definite ed indipendenti l una dall altra, che risiedono su più computer all interno di una rete (ad esempio la rete interna di una azienda o una rete di connessione fra più aziende che collaborano). Ogni servizio mette a disposizione una certa funzionalità e può utilizzare quelle che gli altri servizi hanno reso disponibili, Albanese Francescantonio, Pagina 18

20 realizzando, in questo modo, applicazioni di maggiore complessità. Inoltre, in una Service-Oriented Architecture è possibile modificare rapidamente questi servizi, combinarli, aggiungerne di nuovi, modificare i processi per rispondere alle specifiche esigenze di business e utilizzare i servizi in modo illimitato e personalizzato: il processo di business, in questo modo, non è più vincolato da una specifica piattaforma o da una applicazione ma può essere considerato come un componente e quindi riutilizzato o modificato. SOA è una forma particolare di Distributed System, la cui definizione è la seguente: Un Distributed System (Sistema distribuito) consiste di vari agenti software distinti che devono lavorare insieme per svolgere alcuni compiti, inoltre, gli agenti in un sistema distribuito non operano nello stesso ambiente di calcolo, pertanto devono comunicare per mezzo di stack di protocolli hardware/software su una rete. Questo significa che le comunicazioni in un sistema distribuito sono meno veloci e affidabili rispetto a quelle che utilizzano invocazione diretta del codice e memoria condivisa e ha importanti implicazioni architetturali, perché i sistemi distribuiti richiedono che gli sviluppatori (di infrastruttura e applicazioni) considerino la latenza, fattore imprevedibile dell accesso remoto, e tengano presente questioni relative alla concorrenza e la possibilità di fallimenti parziali. Albanese Francescantonio, Pagina 19

21 2.2 Caratteristiche di una Service-Oriented Architecture Con la Service-Oriented Architecture (SOA) sono definite alcune proprietà, orientate al riutilizzo e all integrazione in un ambiente eterogeneo, che devono essere rispettate dai servizi che compongono il sistema. In particolare un servizio dovrà: essere ricercabile e recuperabile dinamicamente. Un servizio deve poter essere ricercato in base alla sua interfaccia e richiamato a tempo di esecuzione. La definizione del servizio in base alla sua interfaccia rende quest ultima (e quindi l interazione con altri servizi) indipendente dal modo in cui è stato realizzato il componente che lo implementa. essere auto-contenuto e modulare. Ogni servizio deve essere ben definito, completo ed indipendente dal contesto o dallo stato di altri servizi. essere definito da un interfaccia ed indipendente dall implementazione. Deve cioè essere definito in termini di ciò che fa. Questo determina l indipendenza del servizio non solo dal linguaggio di programmazione utilizzato per realizzare il componente che lo implementa ma anche dalla piattaforma e dal sistema operativo su cui è in esecuzione: non è necessario Albanese Francescantonio, Pagina 20

22 conoscere come un servizio è realizzato ma solo quali funzionalità rende disponibili. essere debolmente accoppiato con altri servizi (loosely coupled). Un architettura è debolmente accoppiata se le dipendenze fra le sue componenti sono in numero limitato. Questo rende il sistema flessibile e facilmente modificabile. essere reso disponibile sulla rete attraverso la pubblicazione della sua interfaccia (in un Service Directory) ed accessibile in modo trasparente rispetto alla sua allocazione. Essere disponibile sulla rete lo rende accessibile da quei componenti che ne richiedono l utilizzo e l accesso deve avvenire in maniera indipendente rispetto all allocazione del servizio. La pubblicazione dell interfaccia deve rendere noto anche le modalità di accesso al servizio. Deve mettere a disposizione un basso numero di operazioni, cioè poche funzionalità, in modo tale da non dover avere un programma di controllo complesso. Deve interagire con gli altri servizi attraverso lo scambio di messaggi. Per questo motivo e per il fatto che i servizi possono trovarsi su sistemi operativi e piattaforme diverse è necessario che i messaggi siano composti utilizzando un formato standard largamente riconosciuto. I dati che vengono trasmessi attraverso i messaggi possono essere costituiti sia dal risultato dell elaborazione di un certo servizio sia da informazioni che più servizi si scambiano per coordinarsi fra loro. essere realizzato in modo tale da permetterne la composizione con altri. Albanese Francescantonio, Pagina 21

23 Nell architettura SOA le applicazioni sono il risultato della composizione di più servizi. È per questo motivo che ogni servizio deve essere indipendente da qualsiasi altro, in modo tale da ottenere il massimo della riusabilità. La creazione di applicazioni o di servizi più complessi attraverso la composizione dei servizi di base viene definita Service Orchestration. La composizione può essere definita con riferimento a linguaggi specializzati come BPEL (BPEL4WS, Business Process Execution Language for Web Services). Queste sono le caratteristiche di un sistema di tipo SOA, di cui adesso passiamo a descriverne il funzionamento. 2.3 Come funziona una Service-Oriented Architecture Focalizzando l attenzione sul concetto di servizio, i principali attori in causa sono il fornitore e il richiedente, come nella tipica interazione client server. Attraverso la Service-Oriented Architecture (SOA) questa interazione viene arricchita con un ulteriore attore il Service Directory o Service Broker che si inserisce all interno della comunicazione tra fornitore e fruitore del servizio. Di seguito è riportata una descrizione del ruolo di ognuno dei tre attori coinvolti in un sistema SOA: Albanese Francescantonio, Pagina 22

24 Service Provider Entità che realizza e mette a disposizione un qualche servizio. Tale servizio, per poter essere trovato da altre entità che vogliono utilizzarlo, deve essere reso visibile sulla rete, in termine tecnico Pubblicato. A tal fine il Service Provider descrive il suo servizio usando Web Service Description Language (WSDL) e successivamente lo comunica al Service Registry che la memorizza nella directory dei servizi. Il Sevice Provider resta quindi, in attesa, che un utente richieda i servizi pubblicati. Service Directory o Service Broker Questo componente gestisce la directory dei servizi, permettendo a chi ha necessità, di ricercare un servizio sulla base delle caratteristiche con le quali è stato definito e memorizzato. Il Service Directory possiede quindi le informazioni, come URL e modalità di accesso, di tutti i servizi disponibili. Service Consumer o Service Requester Rappresenta un potenziale utente che richiede un servizio. A tale scopo il Service Consumer interagisce con il Service Directory per ottenere il servizio più adatto ai propri obbiettivi. Una volta individuato si collega al Service Provider corrispondente per fruire del servizio. In figura 2.1 sono riportate le interazioni fra le entità appena descritte. Albanese Francescantonio, Pagina 23

25 Figura 2.1: Esempio di Architettura SOA. Tutte queste interazioni passano attraverso quella che viene genericamente definita Rete di Comunicazione, la quale in un implementazione reale di una SOA può essere costituita sia da Internet sia da una Intranet. SOA definisce, dunque, le caratteristiche che i componenti facenti parte di un sistema devono avere al fine di poter definire quest ultimo un architettura orientata ai servizi. Ai tre ruoli si va ad aggiungere un altra entità: il Service Contract, che definisce il formato per la richiesta di un servizio e per relativa risposta. Poiché i servizi devono essere ricercati e recuperati dinamicamente, il Service Contract deve essere pubblicato su un Service Broker dal Service Provider. Albanese Francescantonio, Pagina 24

26 Va notato che quest entità coinvolte in un sistema SOA, possono essere distribuite sul territorio e possono utilizzare piattaforme differenti, con l unico vincolo di dover utilizzare tutte e tre un canale trasmissivo comune. Rimanendo sul mezzo trasmissivo, questo risulta essere un parametro dell architettura, quindi l approccio adottato dalle SOA ha il vantaggio di potersi integrare con diversi ambienti quali il Web, la telefonia mobile e altri permettendo di realizzare applicazioni multi canale, fruibili attraverso dispositivi di natura molto diversa. 2.4 I Web Services I Web Services sono un nuovo tipo di applicazioni web che cooperano fra loro, indipendentemente dalla piattaforma sulla quale si trovano, attraverso lo scambio di messaggi. Ognuna di queste applicazioni viene chiamato Web Service (Servizio Web), o più semplicemente servizio, del quale il Web Services Architecture Working Group (del W3C 8 ) dà la seguente definizione: Un Web Service è un applicazione software identificata da un Uniform Resource Identifier (URI) 9, le cui interfacce pubbliche e 8 Il World Wide Web Consortium (universalmente noto come W3C) è una organizzazione che sviluppa gli standard ufficiali (specifiche, linee guida, software e strumenti) usati nell ambito di Internet. Questo consorzio, nato nel 1994 con l obiettivo di sviluppare il potenziale del World Wide Web, è neutrale rispetto ai venditori. 9 Uniform Resource Identifier (URI, acronimo più generico rispetto ad "URL") è una stringa che identifica univocamente una risorsa generica che può essere un indirizzo Web, un documento, un'immagine, un file, un servizio, un indirizzo di posta elettronica, ecc. L'URL è un URI, o più comunemente chiamato indirizzo web. Albanese Francescantonio, Pagina 25

27 collegamenti sono definiti e descritti come documenti extensible Markup Language (XML), nello specifico WSDL. La sua definizione può essere ricercata da altri agenti software situati su una rete, i quali possono interagire direttamente con il Web Service, con le modalità specificate nella sua definizione, utilizzando messaggi basati su XML (SOAP), scambiati attraverso protocolli Internet (tipicamente HTTP). Gli standard utilizzati dai Web Services, alcuni citati nella definizione, si basano tutti su XML, e sono: XML Schema (extensible Markup Language Schema), è un linguaggio di descrizione del contenuto di un file XML. Il suo scopo è definire qual è la costruzione legale di un documento XML, in particolare, gli elementi permessi, quali tipi di dati sono ad essi associati e la loro relazione gerarchica, permettendone la validazione, ovvero la verifica che i suoi elementi siano in accordo con la descrizione in linguaggio XML Schema. SOAP (Simple Object Access Protocol), è un protocollo di trasmissione di messaggi tra componenti software in formato XML. SOAP 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. SOAP è un protocollo di alto livello ed è completamente Albanese Francescantonio, Pagina 26

28 indipendente dal protocollo di trasmissione sottostante, che può essere indifferentemente HTTP (Hypertext Transfer Protocol), JMS (Java Message Service), SMTP (Simple Mail Transfer Protocol), MIME (Multipurpose Internet Message Encapsulation) o altri. Tra questi il più usato è HTTP. SOAP è diventato un nome, e non più un acronimo; tuttavia: Service Oriented Architecture Protocol: un messaggio SOAP rappresenta l'informazione necessaria per invocare un servizio o riflette il risultato dell'invocazione di un servizio e contiene l' informazione specificata nella definizione dell'interfaccia del servizio. Simple Object Access Protocol: meccanismo per invocare oggetti remoti, serializzando la lista degli argomenti che deve essere trasportata dall'ambiente locale a quello remoto. WSDL (Web Services Description Language), è un linguaggio formale basato XML, utilizzato per descrivere, in modo completo, un web service. Più precisamente un documento WSDL fornisce informazioni riguardanti l interfaccia del Web Service in termini di: servizi offerti dal Web Service URL ad essi associato modi per l invocazione Albanese Francescantonio, Pagina 27

29 argomenti accettati in ingresso e modalità con cui debbono essere passati formato dei risultati restituiti formato dei messaggi In altre parole si può dire che un file WSDL fornisce la descrizione relativa ad un Web Service in termini di: cosa fa come comunica dove si trova Attraverso tale file si può quindi conoscere tutti i dettagli per poter invocare correttamente un servizio. UDDI (Universal Description, Discovery and Integration), è un registry (ovvero una base dati ordinata ed indicizzata), basato su XML e che utilizza SOAP per le comunicazioni da e verso l esterno. UDDI è indipendente dalla piattaforma hardware e definisce un meccanismo comune per pubblicare e trovare informazioni sui Web Services, in base alle loro descrizioni WSDL. Ciò che UDDI mette a disposizione è un registro nel quale si possa accedere, attraverso specifiche funzioni, per: pubblicare servizi che un azienda rende disponibili cercare aziende che mettono a disposizione un certo tipo di servizio Albanese Francescantonio, Pagina 28

30 avere informazioni Human Readable, cioè comprensibili all utente, circa indirizzi, contatti o altro relativi ad una azienda avere informazioni tecniche Machine Readable, cioè interpretabili ed utilizzabili dalla macchina, relative ad un servizio in modo tale da potersi connettere Un registro UDDI è costituito, in realtà, da un database distribuito, cioè da molti registri distribuiti sulla rete, ognuno dei quali si trova sul server di una azienda che contribuisce allo sviluppo di questo archivio pubblico, e connessi fra loro. Il sistema mantiene una centralizzazione virtuale, cioè l informazione che viene registrata su uno dei nodi (registri) del sistema viene propagata e resa disponibile su tutti gli altri tramite una loro sincronizzazione. Questo, oltre che ad alleggerire il carico di lavoro che un singolo nodo deve sopportare, contribuisce alla protezione del sistema contro possibili situazioni di failure del database, grazie alla ridondanza dei dati. Attraverso l utilizzo di questi ed altri standard i Web Services rendono possibile la comunicazione e la cooperazione, attraverso il web, di più applicazioni (servizi) che mettono a disposizione alcune funzionalità e, allo stesso tempo, utilizzano quelle rese disponibili da altre. Si può cioè ricercare e invocare servizi che possono essere composti per formare un applicazione per l utente finale, per abilitare transazioni di business o per creare nuovi Web Services. Albanese Francescantonio, Pagina 29

31 Di queste tecnologie, XML ha dato un contributo molto importante alla nascita dei Web Services. Linguaggio a marcatori, tag, creato e gestito dal World Wide Web Consortium (W3C) e derivato dallo Standard Generalization Markup Language (SGML) 10, l XML è utilizzato per la memorizzazione di 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 testo e quindi un documento XML può essere letto chiaramente su qualsiasi sistema operativo. Questa indipendenza lo rende la soluzione ideale per lo scambio di informazioni attraverso il Web. I vantaggi offerti dai Web Services sono: Indipendenza dalla piattaforma: i Web Services possono, infatti, comunicare fra loro anche se si trovano su piattaforme differenti Indipendenza dall implementazione del servizio: l interfaccia che un Web Service presenta sulla rete è indipendente dal software che implementa tale servizio. In futuro tale implementazione potrà essere sostituita o migliorata senza che l interfaccia subisca modifiche e quindi senza che dall esterno (da parte di altri utenti o servizi sulla rete) si noti il cambiamento 10 Standard Generalized Markup Language (SGML), è uno standard per la descrizione logica dei documenti. Albanese Francescantonio, Pagina 30

32 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 SOAP di passare attraverso sistemi di filtraggio del traffico sulla rete, quali Firewall Riuso del software: è possibile riutilizzare software implementato precedentemente e renderlo disponibile attraverso la rete Il concetto di Web Services implica quindi un modello di architettura ad oggetti distribuiti (oggetti intesi come applicazioni), che si trovano localizzati in punti diversi della rete e su piattaforme di tipo differente. Il legame con l architettura Service-Oriented Architecture (SOA) sta nel fatto che, sfruttando al meglio tutte le caratteristiche della tecnologia dei Web Services, il sistema che si ottiene implementa proprio un architettura orientata ai servizi. Ad oggi i Web Services rappresentano la soluzione migliore per la realizzazione di una SOA su larga scala, ovvero su Internet. 2.5 Web Services e architettura di tipo non SOA Bisogna specificare, che parlare di Web Services, non implica necessariamente parlare di Service-Oriented Architecture (SOA). Si può ad esempio utilizzare i Web Services per aggiungere ad un architettura esistente una funzionalità basata sui servizi al fine di ottenere un certo Albanese Francescantonio, Pagina 31

33 requisito richiesto dal progetto che si sta realizzando. Oppure si può realizzare un sistema privato, interno ad una azienda, basato sulle tecnologie dei Web Services (fig. 2.3). Figura 2.3: Utilizzo di Web Services in un architettura di tipo non SOA. In questi casi, come in altri, non è detto che si possa definire il sistema realizzato un architettura orientata ai servizi; questo perché, per il Albanese Francescantonio, Pagina 32

34 particolare utilizzo che si fa dei Web Services all interno di un certo sistema software, può non essere necessario soddisfare alcuni requisiti richiesti dal modello di architettura SOA. Poniamo, ad esempio, il caso di una rete interna ad una azienda in cui sono state realizzate applicazioni che fanno uso della tecnologia dei Web Services; se si prevede che le modifiche che verranno apportate nel tempo al sistema non sono in misura elevata, si può ad esempio pensare di memorizzare le informazioni riguardanti tutti i servizi nella configurazione di ognuno di essi, escludendo perciò dal progetto la presenza di un Service Registry, entità prevista invece dal modello di architettura SOA. Un altro possibile utilizzo, molto interessante, dei Web Services è il loro impiego nel processo di integrazione di applicazioni fra più aziende o fra più sedi della stessa azienda, attraverso il Web. Ad esempio si possono avere due aziende partner interessate a mettere a disposizione l una dell altra specifici servizi che si trovano sui propri server, mantenendone però la gestione dell implementazione. I Web Services rendono questo possibile senza doversi preoccupare della compatibilità fra piattaforme, sistemi operativi o linguaggi di programmazione, grazie alla totale indipendenza che questa tecnologia ha rispetto all implementazione del servizio. Albanese Francescantonio, Pagina 33

35 Figura 2.4: Esempio di comunicazione fra Web Service implementati su piattaforme diverse. Un esempio è schematizzato in figura 2.4 dove si ha una cooperazione fra Web Service realizzati su due piattaforme diverse, le due oggi più importanti J2EE (Java 2 Platform, Enterprise Edition) e.net (Microsoft.NET). Il vantaggio di una collaborazione di questo tipo fra più aziende non è solo quello di poter avere accesso diretto attraverso la rete a servizi Albanese Francescantonio, Pagina 34

36 implementati e gestiti da altri ma anche di poterli comporre fra loro, siano essi in locale o in remoto, in modo tale da ottenerne di nuovi che mettano a disposizione nuove funzionalità o che riescano a risolvere problemi di complessità maggiore. Abbiamo visto come possono essere utilizzati i Web Services per interconnettere servizi situati in punti diversi della rete e con caratteristiche differenti. L esempio che abbiamo descritto riferendoci alla figura 2.3 fa uso di riferimenti agli altri servizi di tipo statico; il Client (o Consumer) conosce già l indirizzo (URL) al quale poter trovare un certo servizio (Provider). Si può invece desiderare di non dover conoscere, al momento dell implementazione di un servizio, gli URL di altri servizi di cui farà uso, lasciando ad un ulteriore agente il compito di fornire, a tempo di esecuzione, questa ed altre informazioni. Stiamo parlando del Service Registry ed introduciamo così l utilizzo dei Web Services nella realizzazione di un architettura Service-Oriented. 2.6 Web Services e architettura SOA La presenza del Service Registry (o anche Service Directory o Service Broker), di cui abbiamo già parlato nel capitolo 2.5, è ciò che rende il sistema, nell esempio di utilizzo dei Web Services visto precedentemente (in figura 2.3), un architettura Service-Oriented (SOA). Albanese Francescantonio, Pagina 35

37 Per implementare il Service Registry i Web Services fanno uso di UDDI, Universal Description, Discovery and Integration. UDDI è un servizio di registro pubblico in cui le aziende possono registrare (pubblicare) e ricercare Web Services. Esso mantiene informazioni relative ai servizi come l URL e le modalità di accesso. Anche UDDI è un Web Service, il quale mette a disposizione due operazioni: Publish, per la registrazione Inquiry, per la ricerca Si ottiene così quella che, allo stato attuale, è da molti considerata la migliore soluzione per l implementazione di un sistema con architettura Service Oriented. In figura 2.5 è riportata la schematizzazione del funzionamento di un sistema con architettura SOA, realizzato attraverso l uso dei Web Services. Albanese Francescantonio, Pagina 36

38 Figura 2.5: Sistema con architettura Service-Oriented realizzato con la tecnologia dei Web Services. Albanese Francescantonio, Pagina 37

39 Capitolo 3 Service Oriented Architecture e gli Enterpise Service Bus 3.1 Enterprise Service Bus come infrastruttura di supporto ad architetture Service-Oriented Con le architetture orientate ai servizi, il patrimonio informativo aziendale non è più un insieme di applicazioni tra loro isolate e che comunicano attraverso tecnologie d integrazione di applicazioni, è, invece, organizzato in una collezione di servizi intesi come funzionalità di business realizzate tramite "componenti" che rispettano un'interfaccia standard. La Service-Oriented Architecture promette notevoli miglioramenti nell allineamento dell Information Technology (IT) con le esigenze aziendali ma necessita di un infrastruttura in grado di connettere le Albanese Francescantonio, Pagina 38

40 risorse IT indipendentemente da dove siano implementate, in particolare, necessita di un infrastruttura che offra flessibilità e affidabilità, in grado di riassemblare facilmente i servizi senza interruzioni. Quest infrastruttura è l Enterprise Service Bus (ESB). Un ESB è un infrastruttura software che opera tra le applicazioni ed il sistema operativo (middleware) e che fornisce servizi di supporto ad architetture Service-Oriented (SOA). Il compito principale di un ESB è fornire un layer di comunicazione tra i servizi, coerentemente con i principi architetturali SOA, e permettere l invocazione dei servizi su sistemi eterogenei, risolvendo problematiche legate all integrazione come per esempio il supporto a chiamate sincrone e asincrone basate su messaggi, il routing intelligente dei messaggi, trasformazione e validazione dei dati, integrazione con diversi protocolli, gestione dell affidabilità e sicurezza. È facile, quindi, osservare che queste funzionalità si sovrappongono parzialmente a quelle fornite usualmente dai tradizionali middleware di integrazione da cui, in parte, derivano. Per comprendere pienamente i vantaggi forniti dagli ESB, occorre partire dalle differenze che questi presentano rispetto ai tradizionali sistemi di integrazione basati sull utilizzo di un middleware, di cui rappresentano un evoluzione in senso SOA. In tali architetture denominate Hub-and-Spoke (cosiddetto a stella ), le operazione di routing dei messaggi e trasformazione dei dati sono Albanese Francescantonio, Pagina 39

41 centralizzate nell Hub e svolte dall Integration Broker, il componente centrale del sistema di integrazione. Da un punto di vista architetturale, l Integration Broker rappresenta l interfaccia unica attraverso cui transita ogni richiesta di comunicazione tra sistemi applicativi disomogenei che devono interoperare. In questo modo, tutte le problematiche e le operazioni di integrazione risultano essere centralizzate, riusabili e facilmente amministrabili. Gli svantaggi di un simile approccio nascono dal fatto che l hub rappresenta un potenziale collo di bottiglia, un potenziale single point of failure e presenta difficoltà di scalabilità. Inoltre, gran parte delle suite di integrazione presenti sino ad oggi sul mercato sono state sviluppate in tempi in cui o non esistevano standard per la definizione dei processi operativi o dello scambio dati, oppure questi non erano sufficientemente maturi e stabili. I fornitori software hanno così sviluppato soluzione proprietarie per risolvere le problematiche tipiche dell integrazione. Il risultato di tale investimento da parte dei fornitori dell Enterprise Application Integration (EAI) erano software altamente funzionali ma terribilmente costosi e non flessibili. Anche oggi, questo tipo di software richiede un elevatissima tassa di licenza e un investimento in servizi di consulenza cinque volte superiore rispetto alla tassa di licenza software, per assicurarne il funzionamento. In molti casi, le competenze Albanese Francescantonio, Pagina 40

42 necessarie per lo sviluppo e la gestione di tali soluzioni EAI sono quindi garantite quasi unicamente dal fornitore del prodotto: vi è quindi un chiaro svantaggio tecnico ed economico dovuto non solo al costo delle licenze, ma soprattutto alle necessità per la manutenzione e la consulenza sul prodotto. In passato, l adozione di tali suite ha comportato problemi in termini di costi, manutenzione e interoperabilità. Figura 3.1: Integration Middleware: architettura Hub-and- Spoke Albanese Francescantonio, Pagina 41

43 Figura 3.2: Integration broker: centralizzazione delle funzionalità d integrazione Con l avvento degli Standard Internet vengono descritti come i sistemi informatici debbano connettersi gli uni agli altri, la semantica delle conversazioni tra questi e come i dati debbano essere rappresentati in tali conversazioni ed è proprio tutto questo che ha cambiato il mondo della EAI. Il software EAI comincia ad essere progettato e sviluppato in modo da utilizzare questi standard ad un costo minore rispetto alle soluzioni Albanese Francescantonio, Pagina 42

44 proprietarie. Lavorare con questa nuova generazione di software significa semplicemente ricercare gli standard opportuni e decidere la migliore modalità di implementazione in ambito aziendale. E, dato che le soluzioni sono conformi agli standard, le competenze informatiche necessarie per sviluppare e gestire il software risultano ampiamente disponibili. 3.2 Perché Enterprise Service Bus? Un ESB aiuta le aziende a sfruttare il valore dell architettura SOA incrementando la connettività, aggiungendo la flessibilità che facilita il cambiamento e fornendo maggiore controllo sull utilizzo delle importanti risorse che unisce. Mike Gilpin, Vice President e Research Director What Is An Enterprise Service Bus? Forrester Research, Inc., Agosto 2004 La nascita delle nuove tecnologie che tentano di migliorare i risultati del processo di integrazione, come la Service Oriented Architecture (SOA), l Enterprise Application Integration (EAI) e i servizi web, hanno guadagnato l attenzione dei leader dell Information Tecnology, dei venditori e degli analisti. L Enterprise Service Bus (ESB) racchiude le caratteristiche migliori di tutte queste tecnologie. Un ESB è generalmente progettato per permettere che applicazioni di diverso tipo si scambino messaggi con lo scopo di estendere le funzionalità di ciascuna applicazione con quelle fornite dalle altre Albanese Francescantonio, Pagina 43

45 applicazioni e di rendere virtuali le risorse aziendali, permettendo alla logica di business dell azienda di essere sviluppata e gestita indipendentemente dall infrastruttura della rete, e dalla fornitura di questi servizi. Un ESB è un prodotto per l integrazione basato su standard di mercato, che raccoglie le novità introdotte dallo stile architetturale orientato ai servizi e che fornisce le funzionalità tipiche dei tradizionali Integration Broker di cui ne rappresenta l evoluzione, con due fondamentali differenze. La prima è tecnologica: gli ESB espongono tramite standard quelle funzionalità che i tradizionali Integration Broker fornivano tramite tecnologie proprietarie. Esempi di standard ampiamente utilizzati sono: Java DataBase Connectivity (JDBC) 11, Java Message Service (JMS) 12, Web Services Description Language (WSDL) 13 e altri. 11 JDBC (Java DataBase Connectivity), è un connettore per database che consente l'accesso alle basi di dati da qualsiasi programma scritto con il linguaggio di programmazione Java, indipendentemente dal tipo di DBMS utilizzato. 12 JMS (Java Message Service) è un insieme di API che consente alle applicazioni Java presenti in una rete di scambiarsi messaggi tra loro e definisce lo standard di affidabilità per l'enterprise Messaging (messaging per imprese), il quale è universalmente riconosciuto come una parte essenziale del sistema di applicazioni delle imprese. 13 Web Services Description Language (WSDL) è un linguaggio formale in formato XML utilizzato per la creazione di "documenti" per la descrizione di Web Service. Albanese Francescantonio, Pagina 44

46 Figura 3.3: Architettura Enterprise Service Bus La seconda differenza è architetturale: un ESB non si basa su un architettura monolitica di tipo Hub-and-Spoke, ma su di una architettura distribuita a bus condiviso SOA oriented. In altre parole, in un infrastruttura ESB, tutte le applicazioni sono integrate e operano come servizi. Albanese Francescantonio, Pagina 45

47 Figura 3.4: Enterprise Service Bus: scenario d'integrazione La logica d integrazione non è più centralizzata in un hub, ma è distribuita lungo gli endpoint connessi al bus. Decentralizzando la logica di integrazione lungo il bus si migliora la scalabilità ed è possibile Albanese Francescantonio, Pagina 46

48 effettuare il deploy delle funzionalità d integrazione strettamente necessarie (selective-deployment 14 ). L utilizzo degli standard permette di ridurre le soluzioni proprietarie chiuse e costose tipiche dei tradizionali prodotti EAI riducendo l acquisto di soluzioni proprietarie e i costi legati alle consulenze specialistiche e alle licenze. Risulta evidente che l aumento di interoperabilità dato dall uso di protocolli e tecnologie standard, riduce i rischi aziendali dovuti dall adozione di un middleware, rendendolo in teoria sostituibile. Ad esempio, se ESB utilizza i Web Services, è possibile disaccoppiare l interfaccia del servizio (Web Services Description Language (WSDL)) dall implementazione del servizio stesso. L ESB permette, in linea con le best practices SOA, un'integrazione "incrementale": è possibile infatti integrare in momenti differenti le varie parti di un sistema attraverso un approccio cosiddetto Leave-and-layer: si lascia inalterato l'insieme dei servizi Legacy e di applicazioni esistenti riconciliando le loro differenze (logica e dati) in un nuovo layer (in questo caso, appunto, l ESB). Gli ESB quindi, rispetto ai prodotti tradizionali di integrazione, dovrebbero ridurre i costi di licenze e manutenzione e permettere una maggiore garanzia di portabilità del codice e di interoperabilità. Ad oggi, praticamente quasi tutti i principali 14 Con il termine inglese deployment indica la messa in campo o in atto (letteralmente, lo "spiegamento") di una soluzione. In informatica, in particolare, l'espressione può avere diversi significati a seconda del contesto. Albanese Francescantonio, Pagina 47

49 produttori di Software hanno realizzato o intendono realizzare un proprio prodotto ESB da proporre sul mercato. Da un lato società che proponevano broker di integrazione tradizionali (es: IBM e SeeBeyond) hanno affiancato alla loro suite d'integrazione anche dei prodotti ESB, dall'altro le società di dimensioni più limitate (come Sonic o Fiorano) che proponevano sistemi di comunicazioni a messaggi hanno migliorato il loro prodotto aggiungendo nuove caratteristiche. Altri venditori hanno riadattato le loro integration suite effettuando di fatto una riproposizione del loro prodotto al fine di ridurre i costi (licenze e manutenzione), altri ancora hanno fornito una versione "light" del prodotto Integration Broker in veste di ESB. 3.3 Enterprise Service Bus: Funzionalità supportate Generalmente gli Enterprise Service Bus (ESB) utilizzano come dorsale infrastrutturale un sistema a scambio di messaggi come puro supporto alla comunicazione, integrando poi nel suo stack le funzionalità e i meccanismi che permettono integrazione a livello enterprise. Le funzionalità che un ESB deve implementare e che lo rendono un prodotto di successo, sono: Trasformazione (sintattica e semantica), divisione, aggregazione e arricchimento dei messaggi XML. Questo permette di riconciliare rapidamente incompatibilità tra formati dati utilizzati da servizi Albanese Francescantonio, Pagina 48

50 che interoperano, fondere dati provenienti da diverse fonti ed estendere le funzionalità dei servizi. Delivery dei messaggi con autenticazione, autorizzazione, non ripudio; in generale deve essere garantito il supporto Middleware alla comunicazione asincrona. Mediazione del modello di trasporto, protocollo e interazione. È possibile integrare facilmente servizi che rappresentano tecnologie diverse, senza modificare le applicazioni sottostanti o introdurre interdipendenze. Supporto a diverse modalità conversazionali: sincrona e asincrona. Gestione avanzata del routing dei messaggi, per esempio sulla base del contenuto del messaggio stesso che permette a un servizio di mandare un messaggio senza conoscerne la destinazione. Funzionalità di amministrazione per la gestione e la configurazione del bus. Esposizione di servizi middleware di supporto alla logica di business (per esempio la gestione delle transazioni). Supporto di più protocolli di comunicazione (tramite appositi Adapter 15 ) per facilitare l integrazione. 15 Con il nome Adapter (in italiano adattatore) si denota un design pattern ovvero "una soluzione progettuale generale a un problema ricorrente" utilizzato in informatica nella programmazione orientata agli oggetti. Albanese Francescantonio, Pagina 49

51 Supporto per permettere la composizione dei servizi (orchestration) in processi di business. Gestione del monitoring del management per la gestione delle configurazione, del ciclo di vita dei componenti, e per operazioni di log, tracking e verifica dei servizi. Gestione del Service registry e dei metadata per permettere la catalogazione, la memorizzazione e la relativa ricerca. Gestione della sicurezza nelle comunicazioni, per permettere operazioni di autorizzazione, identificazione e di creazione regole e policy. Parte di queste funzionalità possono essere fornite da un middleware che supporti la comunicazione asincrona a messaggi: rispetto a questo un ESB è l'evoluzione da un puro supporto alla comunicazione ad un sistema integrato di composizione di servizi. Si può affermare che gli ESB realizzano la parte di middleware richiesta da architetture SOA utilizzando sistemi a scambio di messaggi. Albanese Francescantonio, Pagina 50

52 Capitolo 4 Una piattaforma di Integrazione Applicativa: GreenVulcanoESB "Oltre la metà delle grandi aziende disporranno di un enterprise service bus entro la fine del 2006 (0.7 probabilità)" Roy Schulte, Vice President Presentazione: The Future of Application Integration Gartner, Inc., Novembre 2004 Abbiamo visto che l integrazione rappresenta un imperativo aziendale, un passaggio obbligato per generare maggiore efficienza operativa e che l Enterprise Service Bus (ESB) rappresenta la pratica architetturale migliore per implementare un architettura Service-Oriented (SOA). A tutt oggi diverse compagnie di Information Tecnology hanno sviluppato un implementazione dell ESB, lo scopo di questa tesi è quello di proporre l implementazione che è stata sviluppata nell azienda presso la quale ho svolto il tirocinio l Software, azienda operante nel campo dell'integrazione applicativa in ambito Enterprise, presentando poi un esempio di utilizzo dello strumento per configurare la rete UTRAN. Albanese Francescantonio, Pagina 51

53 4.1 Perché GreenVulcanoESB? GreenVulcanoESB è una piattaforma di Integrazione Applicativa, in grado di interfacciarsi a svariati sistemi di natura eterogenea. La sua architettura a plug-in ne permette l'espansione e la personalizzazione, al fine di soddisfare le esigenze più diverse. E' sviluppato interamente nel linguaggio Java, ed è un sistema Enterprise Application Integration (EAI) molto flessibile, semplice ed efficace. I punti di forza sono: Si basa su standard aperti Utilizza un qualsiasi Application Server J2EE 16 compliant Utilizza una architettura a plug-in Ha un costo competitivo Presenta un architettura pluggable con possibilità di realizzare altri adapter a seconda delle esigenze del cliente. 16 J2EE (Java 2 Enterprise Edition) è la versione enterprise della piattaforma java. Essa è costituita da un insieme di specifiche che definiscono le caratteristiche e le interfacce di un insieme di tecnologie pensate per la realizzazione di applicazioni di tipo enterprise. Chiunque può realizzare una implementazione di tali specifiche e produrre application server compatibili con le specifiche J2EE (chiamati, proprio per questo, J2EE compliant ). Albanese Francescantonio, Pagina 52

54 Figura 4.1: Componenti base e Architettura di GreenVulcanoESB Il Virtual Layer Permette l indipendenza dall Application Server J2EE adottato non utilizzando meccanismi proprietari dell Application Server, impiegando invece concetti virtuali come operazioni di dequeue, enqueue, forward e Albanese Francescantonio, Pagina 53

55 call, e meccanismi di code al suo interno (es: JMS) per permettere la comunicazione tra i componenti, assicurando, così, un buon livello di disaccoppiamento e di presa in carico dei messaggi Il Core Costituisce la parte centrale del sistema e contiene i componenti ed i servizi dei quali il cliente necessita. Alcune funzionalità principali sono il workflow, dispatching, data transformation, data compression & decompression, data crypting etc. Workflow Supporta flussi sia short-time che long-time. La persistenza dei dati è assicurata mediante l impiego di una base dati e l attivazione avviene mediante eventi (esempio: arrivo di un file, invocazione Web Service, evento schedulato). Interamente sviluppato con tecnologia J2EE. La creazione e la modifica dei flussi avviene tramite console o plug-in di Eclipse. Dispatcher E il componente responsabile del dispatching dei messaggi. Tramite delle regole configurabili effettua intelligent routing. Comunica direttamente con il Data transformation. La configurazione delle regole avviene tramite la console o plug-in di Eclipse. Albanese Francescantonio, Pagina 54

56 Data crypting Utilizzabile in presenza di dati sensibili, fa uso di una chiave configurabile nel sistema e utilizza metodi di crypting standard. È altamente performante. Data transformation Pensato come modulo generico di trasformazione dei dati. Adotta una sua architettura di tipo pluggable ed ha la possibilità quindi di estendere la capacità di trasformazione. Può eseguire molteplici trasformazioni in cascata e assicura l integrazione tra contesti applicativi tecnologicamente differenti. Data compression & decompression Modulo pensato per agevolare il transito di messaggi di grandi dimensioni. Esso è in grado di comprimere e decomprimere tutto il messaggio o parti del dato (esempio: in caso di Web Service) Integration Suite L Integration Suite è l insieme delle funzionalità offerte dall Application Server sottostante. Sono supportati tutti gli Application Server purché siano J2EE compliant, come ad esempio: BEA WebLogic Server Albanese Francescantonio, Pagina 55

57 JBOSS SeeBeyond SAP NetWeaver Connectivity Layer Lo strato di connettività permette di integrare applicazioni via file, Database, Web Services, oppure creare nuovi adapter a seconda delle esigenze del cliente. Nello specifico, consente di far comunicare il Core e tutti componenti contenuti con i sistemi esterni. Al suo interno troviamo già una serie di adapter: SIO (SAP Interface Object), connettore J2EE Connection Architecture (JCA) con caratteristiche sofisticate che permette molteplici configurazioni con sistemi SAP. DB Adapter, plugin che da la possibilità di intergrarsi con database remoti File Adapter, strumento versatile per leggere, scrivere e trasferire file. È in grado di: Apprendere da un XML di configurazione la struttura di un generico file da trattare Albanese Francescantonio, Pagina 56

58 Leggere e scrivere il contenuto, partendo appunto dal suo XML associato Eventualmente trasferire su un sistema remoto, via FTP, il file generato WebService Adapter, ideato per integrare GreenVulcanoESB in un contesto SOA del cliente. In grado di: Acquisire a run-time il WSDL del servizio da invocare Invocare WebServices per interagire con servizi già presenti nella realtà del cliente Essere invocato in modalità WebService, e quindi offrire servizi per gli altri sistemi JARAD (Java-ARS Remedy Adapter), connettore JCA con caratteristiche architetturali sofisticate, che comunica con l esterno mediante messaggi XML. FileNET Adapter, un connettore JCA con caratteristiche architetturali sofisticate. Permette di inserire, modificare e cancellare item documentali ed attributi all interno di FileNET. Albanese Francescantonio, Pagina 57

59 4.3 Amministrazione e controllo del sistema Per quanto riguarda la parte di Amministrazione e Controllo, Il sistema da la possibilità di monitorare sia le risorse del sistema che l esecuzione dei flussi di integrazione. Dispone di Console di Amministrazione che consente di visualizzare e ripristinare vecchie configurazioni, il controllo degli accessi, creazione e design dei workflow, avviare e arrestare i servizi (singolarmente o in gruppo), configurazione dei vari moduli (es: SIO, Dispatcher, Data transformation etc). 4.4 VulCon (plug-in per Eclipse) L Enterprise Service Bus di GreenVulcano mette anche a disposizione, nella sua versione Enterprise, un plug-in per l Integrated Development Environment (IDE) Eclipse. VulCon (GreenVulcano Console) è un designer sofisticato per la progettazione e l implementazione di flussi di business, che permette di realizzare flussi, sia semplici che complessi, in maniera semplice e intuitiva e senza dover modificare a mano i file di configurazione. Albanese Francescantonio, Pagina 58

60 4.5 DataHandler Uno dei principali plugin del ESB è il DataHandler: è un componente altamente performante e configurabile, che si occupa di eseguire operazioni di CRUD verso i principali RBMS 17 che sono in commercio utilizzando le API JDBC 18. Questo componente è disponibile esclusivamente nella versione Enterprise. Il DataHandler attraverso mappe di trasformazione, elabora l'xml ricevuto in input viene normalizzato in un altro XML, che definisce tipi di dati e valori, necessari a eseguire l'operazione sul database. In seguito, il DataHandler esegue le operazioni sul database configurate per il servizio. In base al tipo di operazione configurata, il DataHandler restituisce un output composto di un report che descrive il risultato dell'operazione, e un XML che, attraverso una mappa di trasformazione, è convertito in un secondo XML definito da uno XSD. La configurazione di questo componente avviene in tre step: 1. Definizione degli XSD di input e output del servizio 17 Il Relational Database Management System (RDBMS) (sistema per la gestione di basi di dati relazionali) è un database management system basato sul modello relazionale. 18 JDBC (Java DataBase Connectivity), è un connettore per database che consente l'accesso alle basi di dati da qualsiasi programma scritto con il linguaggio di programmazione Java, indipendentemente dal tipo di DBMS utilizzato. È costituita da una API, raggruppata nel package java.sql, che serve ai client per connettersi a un database. Fornisce metodi per interrogare e modificare i dati. È orientata ai database relazionali ed è Object Oriented. Albanese Francescantonio, Pagina 59

61 2. Definizione delle mappe di conversione dal formato definito negli XSD creati e viceversa 3. Composizione delle select/update/calls in linguaggio SQL per il ritrovamento/modifica dei dati sul database Il linguaggio utilizzato per le mappe di trasformazione è XSLT UDDI UDDI (Universal Description Discovery and Integration) costituisce l elemento fondamentale in un architettura Enterprise Service Bus. E un registro XML-based che permette il discovery dei servizi da parte di un utente o di una applicazione. E interrogabile tramite invocazione Web Service e restituisce un servizio. Albanese Francescantonio, Pagina 60

62 4.7 I Vantaggi dell'utilizzo di GreenVulcanoESB L ESB GreenVulcano offre molti vantaggi, tra i principali: 1. ESB configurabile e adattabile ad ogni esigenza del cliente 2. Possibilità di modificare i servizi configurati senza bloccare le attività del cliente, grazie all hot deploy (lettura della configurazione a caldo) che GreenVulcanoESB offre. Albanese Francescantonio, Pagina 61

63 3. Grazie al plugin Vulcon è molto intuitiva la configurazione dei servizi, ciò permette un notevole risparmio in termini di effort e costi. 4. Grazie al vasto numero di plugin e adapter si può integrare con sistemi diversi anche per tecnologia di sviluppo. Albanese Francescantonio, Pagina 62

64 Capitolo 5 Configurazione di GreenVulcanoESB per la gestione della rete UTRAN 5.1 L ambiente di lavoro Il lavoro svolto per questa tesi riguarda lo sviluppo di un particolare caso d utilizzo di GreenVulcanoESB per mostrare come è possibile, con questo strumento, centralizzare la gestione delle interconnessioni tra applicazioni, evitando di demandare questo problema alle applicazioni stesse, far comunicare in modo sicuro rapido e affidabile i servizi web esposti da sistemi disparati, creare una composizione di servizi, tenere sincronizzati fra di loro diversi database e discriminare in base ad una particolare esigenza l inserimento in un database piuttosto che in un altro. In particolare si è sviluppato un sistema per la configurazione e la gestione della rete UTRAN. Prima di illustrare il caso d utilizzo sviluppato ed analizzare la relativa configurazione di GreenVulcanoESB, occorre fare una panoramica sulle Albanese Francescantonio, Pagina 63

65 tecnologie e gli strumenti di sviluppo utilizzati, per comprendere meglio l ambiente di lavoro. Come base di dati è stata utilizzata Oracle 19. Il sistema gestisce la progettazione della rete UTRAN ; per tale motivo sono stati creati due schemi: 1. Uno schema di progetto con il requisito di memorizzare tutti i dati creati durante la fase di progettazione 2. Uno schema che memorizza i dati che la rete possiede Come application server 20, sul quale far girare l ESB, è stato utilizzato Jboss. Jboss è un application server open source basato sulla tecnologia Java di Sun. Come IDE (Integrated Development Environment) di sviluppo è stato utilizzato Eclipse con un plugin di GreenVulcano (VulCon) che permette di configurare servizi di integrazione in modo rapido ed efficiente. Eclipse è stato un valido strumento anche per sviluppare una piccola applicazione web, la quale veniva utilizzata dall utente finale per configurare la rete UTRAN. Tale applicazione web al suo interno contiene solo la logica di MVC (Model View Controller), per la configurazione della rete, mentre tutta la logica di Business è stata inserita nei servizi di GreenVulcanoESB. 19 Oracle è uno dei più famosi database management system (DBMS), cioè sistema di gestione di basi di dati, ed è scritto in linguaggio C. Oracle fa parte di quei database detti RDBMS (Relational DataBase Management System), ovvero di quei sistemi di database basati sul Modello Relazionale. 20 Un application server è un software che fornisce l'infrastruttura e le funzionalità di supporto, sviluppo ed esecuzione di applicazioni e componenti server in un contesto distribuito. Si tratta di un complesso di servizi orientati alla realizzazione di applicazioni per il web. Albanese Francescantonio, Pagina 64

66 Come sistema operativo del server sul quale girerà l applicazione è stato usato Sun Solaris 10. Solaris è un sistema operativo Unix, scritto in linguaggio C, che è molto conosciuto e utilizzato per la sua scalabilità e per l introduzione di molte caratteristiche innovative come DTrace, ZFS e Time Slider Che cos è la rete UTRAN? Per capire a fondo le caratteristiche dell ambiente dove si va ad attestare il sistema che è stato sviluppato, facciamo prima una panoramica sulla tecnologia che sta alla base della rete UTRAN La tecnologia UMTS Il sistema UTMS (Universal Mobile Telecommunication System), è un sistema di telecomunicazione radiomobile di terza generazione (3G). Attualmente, il sistema UMTS, ormai caratterizzato da standard quasi mondiali che definiscono le principali proprietà, è in una fase di sviluppo tale, grazie al lancio commerciale in Europa di alcuni gestori, da permettere 21 DTrace è una funzione che offre capacità di osservazione pervasiva e sicura sui sistemi di produzione per velocizzare lo sviluppo e l ottimizzazione di applicazioni basate sullo stack AMP/MARS. ZFS è un file system open source noto per la sua alta capacità e per l integrazione di diversi concetti presi da vari file system in un unico prodotto. Time Slider è una funzione che permette di effettuare il backup automatico dei dati sullo stesso disco utilizzando le caratteristiche uniche del file system ZFS. Albanese Francescantonio, Pagina 65

67 di poter usufruire dei servizi offerti dalla nuova tecnologia con un affidabilità pari a sistemi globalmente diffusi, quali il GSM e il GPRS. Un Sistema Radiomobile è un sistema che permette una connessione tra due terminali, di cui almeno uno può essere in movimento. E possibile, per l utente, eseguire e ricevere chiamate in qualunque zona coperta dal sistema stesso con un elevato grado di qualità. La copertura dell area da parte della rete radiomobile è effettuata attraverso dei punti d accesso chiamati Stazioni Radio Base (SRB). Ogni SRB fornisce l accesso alla stazione mobile, è possibile instaurare un collegamento radio con il mobile stesso, se e solo se è disponibile almeno un canale radio libero. I primi sistemi radiomobili (anni 20-30) facevano uso delle frequenze più basse dello spettro radioelettrico, trasmettendo nella gamma MF (Media Frequenza: MHz). L incremento della conoscenza dei fenomeni elettromagnetici e l evoluzione della tecnologia hanno permesso di utilizzare una sempre più ampia porzione dello spettro, potendo così passare alle gamme di frequenza superiori, giungendo oggi all uso della banda UHF (300 MHz 3 GHz) e delle Microonde. Negli Stati Uniti, in Giappone, e in Europa sono introdotti i primi sistemi commerciali (come AMPS, TACS e NMT). Tutti questi sistemi sono basati su tecniche d accesso e d accesso multiplo a divisione di frequenza (FDMA Frequency Division Multiple Access) (FDD Frequency Division Duplex). Con questa tecnica è assegnata una determinata frequenza per le trasmissioni verso la SRB (Uplink), ed una frequenza diversa per le trasmissioni verso il Albanese Francescantonio, Pagina 66

68 terminale mobile (Downlink). Trasportando esclusivamente servizi voce, la modulazione utilizzata era di tipo analogico (FM) e la banda utilizzata per ciascun canale era di circa 30 KHz. I problemi che questi sistemi incontravano erano prevalentemente dovuti ad effetti di fading (effetto di evanescenza del segnale) e d interferenza tra gli altri utenti, i quali erano risolti con la trasmissione del segnale a potenze relativamente alte, e con il riutilizzo delle stesse frequenze nelle celle non adiacenti. Le difficoltà incontrate nei sistemi della prima generazione hanno fatto crescere l'interesse per lo sviluppo dei sistemi di seconda generazione. Con questi sistemi è introdotto l'uso delle tecniche digitali per la trasmissione del segnale, abbinando alle tecniche di codifica della voce anche sistemi per la correzione d errore e la sicurezza nelle comunicazioni. Ecco quindi che intorno agli anni '90 si affaccia sul mercato la seconda generazione (2G) dei sistemi per telefonia mobile: GSM, D-AMPS, PCS e PDC. Utilizzando tecniche digitali di modulazione s introducono i vantaggi di una maggiore efficienza spettrale e la possibilità di combinare le trasmissioni dati insieme alle trasmissioni di tipo vocale. I primi sistemi sviluppati negli Stati Uniti utilizzavano tecniche d accesso a divisione di tempo (TDMA- Time Division Multiple Access), dove ciascuna portante di 30 KHz era divisa in tre Time-Slot, e ciascuno di questi costituiva un canale d utente. In Europa era standardizzato il GSM che, utilizzando tecniche di modulazione GMSK, consente di dividere una portante di 200 KHz in 8 Time Slot, con conseguente aumento degli utenti che possono essere connessi Albanese Francescantonio, Pagina 67

69 contemporaneamente con una sola cella. Per far fronte alle esigenze di maggiori velocità nella trasmissione dati, in questi anni la seconda generazione si è evoluta verso la generazione 2,5. Un esempio è l'introduzione del GPRS sulle reti GSM, il quale consente una maggiore velocità di trasmissione dati, e una più vasta gamma di servizi offerti (Packet Data). Con questo sistema è ora possibile realizzare delle trasmissioni dati fino a 171 Kbit/s in modalità Always On (sempre connesso). Questo è reso possibile dalla possibilità di adattare il traffico di tipo Packet Data Switched sull attuale retegsm, che per sua natura è di tipo Circuit Data Switched. La differenza consiste nel fatto che, rispetto al sistema GSM tradizionale, un collegamento dati GPRS utilizza le risorse di rete solamente quando i dati sono effettivamente trasmessi, ed un utente potrà quindi avere tariffe più orientate verso la quantità dei dati trasmessi indipendentemente dal tempo effettivo della connessione. Nel 1992 la WARC (World Administrative Radio Conference) ha individuato la banda dei 2 GHz per l'utilizzo dei sistemi della terza generazione, e dal 1997 i sistemi che vi operano sono standardizzati da uno specifico gruppo di lavoro in ambito ITU prendendo il nome di IMT UMTS è il nome dei sistemi di terza generazione. Le bande utilizzate nei vari paesi sono pressoché le stesse, ma l'idea originale di realizzare un unica interfaccia radio standardizzata a livello mondiale non ha avuto seguito, pertanto, anche se i sistemi di questa generazione presentano in ogni caso Albanese Francescantonio, Pagina 68

70 molte similitudini, più che uno standard, l IMT-2000, è da considerarsi come una famiglia di sistemi alla quale l UMTS appartiene. Le bande individuate dal WARC verranno utilizzate in Europa e in Asia con tecniche W-CDMA (Wideband Code Division Multiple Access) e TD- CDMA (Time Division - Code Division Multiple Access), mentre negli USA queste bande sono già utilizzate dal sistema PCS, pertanto gli operatori dovranno condividere con questo sistema le risorse radio disponibili. L UMTS inizialmente è standardizzato in Europa dall ETSI fino al 1998, poi nasce il 3GPP (3rd Generation Partnership Project), associazione dei maggiori enti di standardizzazione internazionali (europei, giapponesi, americani, coreani, ecc.). L'UMTS sarà allocato nelle bande di frequenza simmetriche (per il duplex) di MHz per l'uplink, e MHz per il Downlink (modo FDD Frequency Division Duplex), nonché nelle bande asimmetriche da MHz e MHz (modo TDD Time Division Duplex). In entrambi i casi, le bande sopra riportate sono suddivise in portanti da 5 MHz. In particolare in Italia le frequenze assegnate ad H3G (3), primo gestore di telefonia mobile ad aver lanciato in Europa la rete UMTS a livello commerciale, sono le seguenti: per la banda asimmetrica (TDD) per la banda simmetrica in Uplink (FDD) per la banda simmetrica in Downlink (FDD) Albanese Francescantonio, Pagina 69

71 La decisione di utilizzare modalità diverse per l'accesso radio comporta la necessità per i terminali mobili di dover supportare i differenti standard. I primi terminali UMTS supportano anche il sistema di seconda generazione GSM e solo in futuro potranno supportare anche le altre reti 3G. La possibilità per i terminali di potersi collegare anche alle reti della seconda generazione consentirà una maggiore mobilità, specialmente nelle prime fasi d implementazione della rete UMTS giacché non sarà coperta da subito la totalità del territorio. I servizi che un utente sottoscrive con un operatore saranno mantenuti anche in condizione di mobilità verso altri operatori UMTS (servizio chiamato roaming), sfruttandone le capacità di "Virtual Home Environment" (VHE). È inoltre allo studio una modalità di trasmissione a più portanti che consentirà di creare una compatibilità tra i sistemi UMTS e quelli CDMA L'introduzione della tecnica W-CDMA, combinata alle tecniche di codifica variabile (OVSF) utilizzate per le canalizzazioni e all'utilizzo di opportuni algoritmi per il controllo della potenza (Power Control), consentono di realizzare delle connessioni a differenti velocità per ciascun utente, e sarà possibile utilizzare servizi multipli in contemporanea, garantendo la qualità del servizio in ogni momento della connessione pur utilizzando un unica risorsa fisica (Bearer Channel). L'obiettivo è in ogni modo quello di poter realizzare connessioni a 128 Kbit/s in condizioni di mobilità veicolare (fino a 500 Km/ora), connessioni Albanese Francescantonio, Pagina 70

72 a 384 Kbit/s in condizioni di mobilità pedestre, per arrivare fino a 2 Mbit/s in condizioni di ridotta mobilità. Per rendere più flessibili i servizi che una rete UMTS può offrire, le interconnessioni dei vari elementi di rete saranno realizzate con la tecnica ATM (interfacce Iu e Iur). Questa soluzione consente di interfacciare la rete ad accesso radio con la rete centrale in modo molto dinamico, e darà la possibilità di introdurre futuri cambiamenti nella struttura della rete senza dover intervenire direttamente sull'utran (UMTS Terrestrial Radio Access Network), permettendo così uno sviluppo graduale ed in linea con le varie strategie adottate dai singoli operatori Architettura di base del sistema UMTS La rete UMTS utilizza la stessa architettura già impiegata da tutti i sistemi di seconda generazione e da alcuni di prima generazione. Dal punto di vista funzionale gli elementi di rete sono raggruppabili nell UTRAN, che gestisce tutte le funzionalità radio, e nella Core Network (CN) responsabile della commutazione e dell instradamento delle chiamate e delle connessioni con le reti esterne. Albanese Francescantonio, Pagina 71

73 Per completare la panoramica dei sistemi occorre considerare gli apparati d utente (User Equipment UE) che s interfacciano tra l utente e la rete d accesso. Dal punto di vista delle specifiche e degli standard, sia gli apparati d utente sia la rete UTRAN implementano protocolli assolutamente nuovi, progettati sulla tecnologia d accesso radio UMTS; al contrario, la definizione ed i protocolli della CN sono in gran parte mutuati dal GSM. Questa caratteristica consente ai sistemi dotati delle nuove interfacce radio di poter essere integrati con una tecnologia di CN già matura, conosciuta e consolidata, favorendo la rapidità d introduzione delle nuove tecnologie e il roaming globale. L UE si suddivide in due parti: - Il Mobile Equipment (ME) è il terminale utilizzato per le comunicazioni radio sull interfaccia Uu. - L UMTS Subscriber Identity Module (USIM) è la smartcard che immagazzina e gestisce l identità del sottoscrittore, esegue gli algoritmi d autenticazione, memorizza le chiavi d autenticazione e crittografia ed altre specifiche funzionalità necessarie al normale funzionamento del terminale. L UTRAN è formata dai seguenti nodi di rete: - Il Nodo B, che converte il flusso di dati tra le interfacce Iub e Uu e coopera nella gestione delle risorse radio (il termine Nodo B ha significato analogo al termine più generico Stazione Radio Base - SRB). - Il Radio Network Controller (RNC), che gestisce e controlla le risorse radio del proprio dominio (i Nodi B si connettono a quest elemento); il nodo RNC costituisce il punto d accesso di tutti i servizi che l UTRAN fornisce alla Albanese Francescantonio, Pagina 72

74 CN come, ad esempio, la connessione ai terminali d utente (UE). S interfaccia con la CN (di solito con un MSC e un SGSN) e termina il protocollo RRC (Radio Resource Control) che definisce i messaggi e le procedure tra il terminale mobile e la rete UTRAN. Corrisponde, logicamente, al nodo BSC del GSM. L insieme di un Radio Network Controller (RNC) e più Nodi B forma il Radio Network Sub-System (RNS). - HLR (Home Location Register): base dati installata presso la rete home che memorizza i profili di servizio degli utenti. Il profilo d utente è creato nel momento in cui il nuovo cliente sottoscrive il servizio e rimane memorizzato finché la sottoscrizione è attiva. Per supportare l instradamento verso il mobile dei servizi da esso terminati (chiamate entranti o messaggi) l HLR memorizza anche la posizione dell UE a livello di MSC/VLR e/o SGSN dal quale il terminale è servito. - MSC/VLR (Mobile Services Switching Centre / Visitor Location Register): sono, rispettivamente, la centrale di commutazione (MSC) e la base dati (VLR) che supportano l UE, nella sua attuale posizione, per i servizi a commutazione di circuito (Circuit Switched CS). La funzionalità principale dell MSC è di commutare le chiamate mentre il VLR memorizza i profili d utente dei sottoscrittori ospiti (ovvero sotto la copertura radio servita dal MSC/VLR) e informazioni più precise quali la posizione dell utente all interno della copertura radio. La parte di rete alla quale si accede tramite MSC/VLR è definita spesso come Dominio a Commutazione di Circuito o CS (Circuit Switched). Albanese Francescantonio, Pagina 73

75 - GMSC (Gateway MSC): è il nodo di commutazione che interfaccia la PLMN (Public Land Mobile Network) UMTS con le altre reti esterne a commutazione di circuito. Tutte le connessioni, entranti e uscenti, di tipo CS passano attraverso il GMSC. - SGSN (Serving GPRS Support Node): funzionalmente simile all MSC/VLR ma utilizzato per servizi a commutazione di pacchetto (Packet Switched PS). - GGSN (Gateway GPRS Support Node): funzionalmente simile al GMSC ma utilizzato per i servizi PS. Si osservi, inoltre, che reti esterne di tipo CS possono essere la rete ISDN (Integated Service Digital Network) o la rete PSTN (Public Switched Telephone Network), mentre reti PS possono essere reti come Internet. Gli standard UMTS sono strutturati in modo che le funzionalità interne degli elementi di rete non siano specificate in dettaglio, mentre lo sono le interfacce tra gli elementi logici di rete. Le interfacce aperte specificate dallo standard per la rete d accesso sono le seguenti: - Interfaccia Cu. Interfaccia elettrica tra la smartcard USIM ed il ME, realizzato conformemente agli standard per smartcard. - Interfaccia Uu. E l interfaccia radio W-CDMA attraverso la quale il terminale d utente accede alla parte fissa dell architettura di rete. Si tratta dell interfaccia aperta più importante dell UMTS. - Interfaccia Iu. Connette l UTRAN alla CN. Questa interfaccia aperta permette agli operatori di acquistare UTRAN e CN da manifatturiere diverse. Albanese Francescantonio, Pagina 74

76 E basata su trasporto ATM (Asynchronous Transfer Mode). Il livello fisico di questa interfaccia è realizzato in fibra ottica, collegamento radio o cavo in rame. - Interfaccia Iur. Questa interfaccia aperta consente il soft handover tra gli RNC di diverse manifatturiere ed è, quindi, complementare rispetto all interfaccia Iu. Anche questa interfaccia è basata su un livello di trasporto ATM. - Interfaccia Iub. Connette i Nodi B all RNC. L UMTS è il primo sistema radiomobile commerciale dotato d interfaccia completamente aperta tra il nodo di controllo e le stazioni radio base. Questo per permettere maggiore competizione tra le diverse manifatturiere impegnate nella realizzazione di Nodi B. Come l interfaccia Iur anche la Iub implementa un livello di trasporto su ATM. Particolare caratteristica della rete UTRAN è quella relativa alle funzionalità logiche del nodo RNC. L RNC che controlla il Nodo B (ovvero che termina l interfaccia Iub proveniente dal Nodo B) è detto Controlling RNC (CRNC) del Nodo B. Il CRNC è responsabile della gestione del traffico e delle situazioni di congestione delle proprie celle. Nel caso in cui una connessione mobile - UTRAN utilizzi le risorse appartenenti a più di un RNC (condizione di Soft Handover Inter RNC) gli RNC coinvolti hanno due ruoli distinti: 1. Serving RNC. L SRNC di un terminale mobile è l RNC che termina il collegamento Iu per il trasporto dei dati utente e la corrispondente segnalazione verso la CN. Un UE può avere sempre un solo SRNC. Albanese Francescantonio, Pagina 75

77 2. Drift RNC. Il DRNC è un qualunque RNC, diverso e distinto dall SRNC, che controlla le celle utilizzate dal terminale mobile. Il DRNC non esegue le elaborazioni del livello 2 (trasporto) ma instrada in maniera trasparente i dati tra le interfacce Iub e Iur. Un UE può avere nessuno, uno o più DRNC. 5.3 Scenario del sistema Il sistema creato tramite l ESB GreenVulcano per configurare e gestire la rete UTRAN è un sistema molto complesso ed è stato sviluppato in un team di progetto diviso in tre sezioni. Una sezione si è dedicata allo sviluppo della parte database e store procedures; un altra sezione si è dedicata allo sviluppo della web application e della console di interfaccia; infine un'altra sezione, cui il sottoscritto ha fatto parte, si è dedicata alla configurazione dei servizi sull ESB. Per il sistema sono stati previsti due database, uno che gestisce le informazioni riguardanti la rete nel suo complesso e uno che gestisce i progetti dei vari utenti e gli elementi di rete da essi manipolati. La console web messa a disposizione dell utente espone varie funzionalità di gestione della rete UTRAN ; tra le principali ci sono tutte le operazioni Albanese Francescantonio, Pagina 76

78 riguardanti la configurazione della rete eseguibili da un area di progetto che è divisa in varie action. Le action sono le funzionalità principali e sono a loro volta divise in task. I task sono le operazioni effettive che un utente può fare all interno del suo progetto. Esempi di task sono: Creazione e cancellazione di nuovi elementi di rete come Node B, Celle e Configurazione Trasmissiva Creazione e cancellazione di Servizi, Coverage e Adiacenze tra Celle Cambio di parametri di ogni elemento di rete e servizio Rehoming Al fine di sfruttare al meglio le potenzialità dell ESB si è scelto di non aggiungere alcuna logica di Business sulla web application, sviluppandola tutta all interno di GreenVulcanoESB. L'ESB, avendo anche capacità di orchestrazione dei servizi (e quindi funzionalità di Business Process Management 22 (BPM)), può esporre un servizio composto che effettua operazioni (inserimenti, cancellazioni, chiamata a store procedure, etc.) sulle tabelle di tutti i database dei sistemi coinvolti, rendendoli sincronizzati. Grazie alla sua capacità di orchestrazione 22 Il Business Process Management è l insieme di attività necessarie per definire, ottimizzare, monitorare e integrare i processi aziendali, al fine di creare un processo orientato a rendere efficiente ed efficace il business dell azienda. Albanese Francescantonio, Pagina 77

79 (attraverso il workflow engine di cui ogni ESB è dotato) l'esb riesce anche a discriminare su quale sistema operare. Le interazioni tra sistemi avviene tramite delle ws-call, che sono un tipo di Virtual Middleware Operation 23 che l ESB mette a disposizione. Tutta la configurazione dei servizi di GreenVulcanoESB è scritta in file XML; tra i più importanti ci sono: 1. GVCore: contiene tutte le operazioni e l ordine con cui devono essere eseguite. In particolare contiene le configurazioni dei servizi, dei sistemi che invocano i servizi, dei plugin e delle trasformazioni XSL utilizzate. 2. GVAdapters: contiene le configurazioni dei vari DataProvider, dei WebServices e dei driver JDBC con i relativi DataSource. 3. GVSupport: contiene le configurazioni dei file di log con i relativi livelli di logging ( info, debug, error ) per ogni componente, plugin o adapters. 23 Le Virtual Middlware Operation sono le chiamate in uscita dal bus, rappresentano il dialogo verso l esterno e possono essere sia chiamate a DB_call (per esempio una insert direttamente dal bus senza un servlet container per far girare i web services e quindi senza passaggi intermedi con ws_call), operazioni sul file system o semplici ws call (chiamate a servizio Web). Albanese Francescantonio, Pagina 78

80 5.4 Configurazione di GreenVulcanoESB La figura 5.2 mostra la configuration console di GreenVulcanoESB accessibile all indirizzo 24, ovvero, la schermata principale del BUS. Questa console rappresenta l interfaccia di configurazione del bus. Da qui, è possibile eseguire le seguenti operazioni: 1. Esportare tutta la configurazione di GreenVulcano 2. Cambiare la configurazione di qualsiasi servizio deployato sull ESB 3. Fare operazioni di monitoraggio di servizi, log, RAM busy, etc. 4. Eseguire test di qualsiasi servizio deployato 5. Ricaricare nuove configurazioni Figura 5.2: Schermata principale della console di GreenVulcanaESB 24 corrisponde a dove <server> è l indirizzo IP del server o il nome del server che ospita l applicazione, in questo caso localhost si riferisce al sistema in uso e <port> è la porta di ascolto del server. Albanese Francescantonio, Pagina 79

81 Oltre a poter configurare l ESB da console di amministrazione è possibile, come già detto in precedenza, farlo in maniera molto più semplice e intuitiva tramite il plug-in VulCon di Eclipse. La figura 5.3 mostra la schermata generale di VulCon con le sezioni dedicate alla configurazione dei tre file principali dell ESB: Core, Adapters e Variables. Figura 5.3: Schermata generale di VulCon Albanese Francescantonio, Pagina 80

82 I servizi creati e configurati sull ESB per il sistema realizzato, sia tramite plug-in VulCon che tramite console, sono moltissimi. Le operazioni effettuate dai servizi chiamano la loro relativa configurazione che avviene nell area dei sistemi (per sistema si intende un sistema esterno con il bus comunica per invocare servizi web o operazioni sul database), come si può vedere dalla figura 5.3. In GreenVulcanoESB bisogna dichiarare i sistemi coinvolti nell'espletamento dei vari servizi. Ogni sistema avrà uno o più canali di comunicazione all'interno del quale vengono raggruppate le Virtual Middleware Operation (VMO). Per questo progetto è stato configurato un solo sistema, DAMA con due canali di comunicazione, CHANNEL_LOADER e CHANNEL_WEBGUI. Ora verrà mostrato, come esempio, uno dei workflow più complessi e andremo ad analizzarlo nel dettaglio. Export Project: input: Identificativo del progetto output: OSS file Albanese Francescantonio, Pagina 81

83 Figura 5.4: Activity Diagram per il servizio EXPORT_PROJECT La figura 5.4 mostra l Activity Diagram UML dal quale si è partiti per la realizzazione del servizio che andremo ora a descrivere. Albanese Francescantonio, Pagina 82

84 Figura 5.5: Workflow per il servizio EXPORT_PROJECT Servizio EXPORT_PROJECT: La figura 5.5 mostra la configurazione del servizio EXPORT_PROJECT. Questo servizio è stato realizzato per rendere effettive e permanenti le modifiche effettuate alla rete che l utente ha realizzato nella sua area di progetto. In pratica l utilizzatore configura le modifiche in locale, nel senso che sono visibili solo nella sua area di progetto; poi una volta terminate, grazie a questo servizio, le rende effettive nella rete. Questo perché il servizio genera tutti i file xml che leggerà l OSS, creando, cancellando o modificando realmente elementi della rete UTRAN. Naturalmente i servizi Albanese Francescantonio, Pagina 83

85 dell ESB GreenVulcano, unitamente alla configurazione dei database, forniscono ampia garanzia di gestione sicura dei dati condivisi, nel senso che due utenti non possono agire sugli stessi elementi di rete contemporaneamente. Andando più in dettaglio nel workflow vediamo che i nodi rappresentano operazioni diverse effettuate dall ESB e ognuna di esse riceve un input rappresentato da un buffer che viaggia all interno del bus. Dopo aver elaborato il suo processo, in base al tipo di operazione, ogni nodo restituisce un output, rappresentato sempre da un buffer che può essere anche lo stesso dell input, che sarà l input dell operazione successiva e così via fino alla fine del servizio. Inoltre ci sono alcuni nodi di check che servono a controllare il risultato dell elaborazione precedente e nel caso effettuare operazioni diverse se si è verificata un eccezione. Il servizio EXPORT_PROJECT riceve in input, dalla web gui, l identificativo, inteso come chiave primaria del database, del progetto che si vuole esportare. Il primo nodo del flusso, select_actions, effettua un operazione di select sul database tramite il DataHandler; in pratica seleziona tutte le azioni effettuate in quel progetto. Il passo successivo è quello di andare a controllare il risultato dell operazione effettuata dal DataHandler tramite il nodo di check, che in caso di eccezione la cattura e ritorna alla WebGui così che l utente possa essere a conoscenza di ciò che accade e perché. Come si può vedere dalla figura 5.4 tutti i nodi di check del workflow convergono in un unico nodo, set_exception_property ; questo nodo è un Albanese Francescantonio, Pagina 84

86 nodo del tipo ChangeGVBuffer sul quale viene agganciato uno script ognl 25 che cattura l eccezione e la setta come property del buffer dell ESB. Script OGNL: #exc=#environment.get('last_gv_exception'), #sw=new java.io.stringwriter(), #pw=new java.io.printwriter(#sw), #exc.printstacktrace(#pw), #pw.close(), property['exception_stack']=#sw.tostring(), object='<root/>' Se il check va a buon fine si passa al nodo export_for_single_action. Questo è un nodo particolare, perché è un IteratorCoreCall, cioè appunto un nodo che itera in base a un Collection Data Provider e per ogni iterazione effettua una chiamata a un altro servizio, il quale riceverà nel buffer di input una property settata tramite un Object Data Provider. Inoltre è stata settata una condition per uscire dall iterazione in caso di eccezione. Per comprendere la funzionalità del Collection Data Provider va spiegato che il DataHandler, per effettuare le sue operazioni, riceve i parametri in ingresso e restituisce l output in file XML che sono nel seguente formato: 25 L Object-Graph Navigation Language (OGNL) è un linguaggio open-source per Java, che, anche utilizzando semplici espressioni, permette di impostare e ottenere property ed eseguire metodi di classi Java. Albanese Francescantonio, Pagina 85

87 <RowSet> <data> <row> <col>valore</col> </row> </data> </RowSet> I Data Provider si settano sul file XML di configurazione GVAdapters o nella sezione Adapters di VulCon come si può vedere dalla figura 5.3. Quindi il nostro Collection Data Provider è stato configurato con l applicazione di una espressione xpath 26 che naviga nei nodi del file XML di output del DataHandler e seleziona le singole azioni restituite dalla select effettuata. 26 XPath (XML Path Language ) è un linguaggio parte della famiglia XML che permette di individuare i nodi all'interno di un documento XML. Le espressioni XPath, a differenza delle espressioni XML, non servono a identificare la struttura di un documento, bensì a localizzarne con precisione i nodi. Albanese Francescantonio, Pagina 86

88 Collection Data Provider XPATH Expression: /RowSet/data/row/col/text() L Object Data Provider che setta la property del buffer è stato, invece, configurato con un espressione ognl. Object Data Provider OGNL Expression: property['action_id']=object.nodevalue Una volta che finiscono le iterazioni e le elaborazioni dei servizi chiamati (che vedremo più avanti), viene controllato il tutto da un altro nodo di check e, se tutto è andato a buon fine, viene elaborato il nodo create_zip_file. Questo nodo è sempre un nodo del tipo ChangeGVBuffer al quale viene applicata un espressione ognl che crea un file ZIP contenente tutti i file ZIP restituiti dal servizio EXPORT_ACTION. Script OGNL: property['zip_prj_file_name']=#tempfile.getcanonicalpath(), #outstream=new java.io.fileoutputstream(#tempfile,true), #zos=new java.util.zip.zipoutputstream(#outstream), object.{ (#this instanceof java.lang.string) && ( Albanese Francescantonio, Pagina 87

89 #filename=#this, #instream=new java.io.fileinputstream(#filename), #bytearray=new byte[2048], #zipentry= new java.util.zip.zipentry(#filename.substring(#filename.lastindexof('/'))), #zos.putnextentry(#zipentry), #loop = :[#this>-1 && (#zos.write(#bytearray,0,#this), #loop(#instream.read(#bytearray)))], #loop(#instream.read(#bytearray)), #zos.closeentry(), new java.io.file(#filename).delete() ) }, #zos.close(), #outstream.close() Dopo aver creato il file ZIP e controllato che tutto sia andato a buon fine, viene invocata l operazione di lettura del file nel nodo read_zip_file, che utilizza l operazione filereader sempre definita nel canale CHANNEL_WEBGUI del sistema DAMA. Dopodiché, se tutto è andato bene, si passa al nodo prepare_for_dh, che è un nodo ChangeGVBuffer che, tramite espressione ognl, costruisce il file XML da dare in input al DataHandler. Albanese Francescantonio, Pagina 88

90 Script OGNL: property['zip_prj_file_deleted']=new java.io.file(property['zip_prj_file_name']).delete(), property['dh_service_name']='dama::export_project_save_zip', #prjid=property['prj_id'], tring(object), #xmlstring = "<RowSet><data><row id='1'></row><row id='2'/><row id='3'/></data></rowset>", #docel=#root.documentelement, #data=#docel.getfirstchild(), #row=#data.getfirstchild(), #col=#root.createelement('col'), #col.appendchild(#root.createtextnode(#prjid)), #row.appendchild(#col), #col=#root.createelement('col'), #col.setattribute('type', 'base64'), #col.appendchild(#root.createtextnode(#stringencode)), #row.appendchild(#col), #col=#root.createelement('col'), Albanese Francescantonio, Pagina 89

91 #col.appendchild(#root.createtextnode('export_' + #prjid + '.zip')), #row.appendchild(#col), object=#root Se tutto è andato a buon fine si passa al nodo save_attachment, che effettua il salvataggio del file ZIP sul database tramite il DataHandler. Infatti il DataHandler può effettuare qualsiasi tipo di operazione sul database e nel caso in questione effettua una chiamata a una store procedure passandogli i parmetri in ingresso che abbiamo definito nell XML di input. Alla fine, se anche l operazione di salvataggio è andata a buon fine, si passa al nodo call_check_result, che è un nodo del tipo CoreCall, cioè che effettua una chiamata singola a un altro servizio. Vediamo ora questo servizio che è un servizio generico richiamato anche dal nodo che setta la property di eccezione e da altri servizi del sistema realizzato. Albanese Francescantonio, Pagina 90

92 Servizio CHECK_RESULT: Figura 5.5: Workflow per il servizio CHECK_RESULT Questo servizio è stato implementato per generare un XML che verrà restituito alla WebGui, la quale ne legge alcune property e, a seconda del loro valore, all utente verrà mostrato un messaggio di esito positivo o negativo dell export. In caso di esito negativo, poiché tutto il flusso EXPORT PROJECTS è in un unica transazione, avverrà una RollBack totale che permetterà all utente di mantenere l integrità dei dati sul DataBase, come erano prima dell invocazione del servizio. Andiamo ad analizzarlo nel dettaglio: Albanese Francescantonio, Pagina 91

93 il primo nodo è un nodo di check come abbiamo già visto nel servizio precedente, solo che in questo caso, oltre a gestire i due casi di default ed eccezione, gestisce anche un ulteriore caso di routing. Per effettuare ciò è stata settata una condition, agganciata alla freccia di connessione del nodo di check, che verifica se la property del buffer EXCEPTION_STACK è valorizzata con l eccezione o meno. In caso di verifica positiva della condition si passa al nodo operation_error che è un nodo ChangeGVBuffer sul quale è agganciata una Trasformazione XSL 27 che crea l XML di output nel caso si sia verifica un eccezione. In caso che la condition non si verifichi il nodo di check intraprende l opzione di default e passa al nodo ChangeGVBuffer operation_correct, che sempre grazie a una Trasformazione XSL crea l XML di output di successo dell operazione. Torniamo ora al servizio EXPORT_PROJECT e andiamo ad analizzare il servizio chiamato da quest ultimo, cioè EXPORT_ACTION. Servizio EXPORT_ACTION: input: Identificativo dell action 27 L'XSLT (extensible Stylesheet Language Transformations) è il linguaggio di trasformazione dell XML; deriva direttamente dal linguaggio XSL, infatti i file di questo formato sono essenzialmente file di testo, contengono elementi ed attributi ed hanno l'estensione ".xsl". L'XSLT è diventato uno standard web con una direttiva (Recommendation) W3C del 16 Novembre L'obiettivo principale per cui l'xslt è stato creato è rendere possibile la trasformazione di un documento XML in un altro documento anche XML. Albanese Francescantonio, Pagina 92

94 output: File.ZIP Figura 5.6: Activity Diagram per il servizio EXPORT_ACTION La figura 5.6 mostra l Activity Diagram dal quale si è partiti per la realizzazione del servizio Export Action che ora vedremo. Albanese Francescantonio, Pagina 93

95 Figura 5.7: Workflow per il servizio EXPORT_ACTION Questo servizio riceve in input l identificativo della action, passatogli dal servizio chiamante tramite property del buffer. Il primo nodo select_tasks effettua una select sul database tramite DataHandler e recupera tutti i task con i relativi task_type effettuati da quella action. Una volta fatto ciò e controllato che l operazione è andata a buon fine si passa a un altro nodo del tipo IteratorCoreCall come visto per il servizio EXPORT_PROJECT, il quale è sempre configurato con un Collection Data Provider e un Object Data Provider. Albanese Francescantonio, Pagina 94

96 Collection Data Provider XPATH Expression: /RowSet/data/row Object Data Provider OGNL Expression: 'col[1]/text()'), 'col[2]/text()') Il risultato dell elaborazione del servizio chiamato viene controllato da un nodo di check e passato al nodo ChangeGVBuffer array_to_xml, il quale trasforma ciò che gli arriva nel buffer in input che è un array in un file XML e setta una property booleana in base a se ci sono o meno dati da esportare, il tutto tramite uno script ognl. Script OGNL: #docel=#root.documentelement, #exportdataexists = 'false', object.{ #this.{ #this.{ Albanese Francescantonio, Pagina 95

97 #currentnode = (#this instanceof org.w3c.dom.document? #this.documentelement : #this), #newnode = #root.importnode(#currentnode, true), #docel.appendchild(#newnode), #exportdataexists = 'true' } } }, property['export_data_exists'] = #exportdataexists, t) In seguito si passa a un nodo di check che effettua routing su tre diverse possibilità; infatti, oltre al solito discorso sull eccezione, il nodo prevede una condition in base alla property booleana settata nel nodo precedente. Se questa property è false il flusso termina, altrimenti continua e si passa al nodo map. Questo nodo è un ChangeGVBuffer al quale è agganciata una Trasformazione XSL che realizza una fusione di tutti i frammenti di EXPORT XML. Infine si passa al nodo create_zip_file che realizza un file ZIP dei file XML creati tramite script ognl. Script OGNL: Albanese Francescantonio, Pagina 96

98 property['zip_file_name']=#tempfile.getcanonicalpath(), #outstream=new java.io.fileoutputstream(#tempfile,true), #zos=new java.util.zip.zipoutputstream(#outstream), #index=1, #nldel=#xml.selectnodelist(object, "/root/lock[modifier='delete']"), #nldel==null ( #loop = :[ #this<#nldel.length && ( #bytearray=#xml.serializedomtobytearray(#nldel.item(#this)), #zipentry= new java.util.zip.zipentry(#index + '_' + 'DELETECONFIG' + '.xml'), #zos.putnextentry(#zipentry), #zos.write(#bytearray,0,#bytearray.length), #zos.closeentry(), #index=#index +1, #loop(#this+1) )], #loop(0) ), #nlrnc=#xml.selectnodelist(object, '/root/cnf:bulkcmconfigdatafile'), #loop = :[ #this<#nlrnc.length && ( #bytearray=#xml.serializedomtobytearray(#nlrnc.item(#this)), Albanese Francescantonio, Pagina 97

99 #zipentry= new java.util.zip.zipentry(#index + '_' + #RNCName + '_' + + '.xml'), #zos.putnextentry(#zipentry), #zos.write(#bytearray,0,#bytearray.length), #zos.closeentry(), #index=#index +1, #loop(#this+1) )], #loop(0), #nlcreate=#xml.selectnodelist(object, "/root/lock[modifier='create']"), #nlcreate==null ( #loop = :[ #this<#nlcreate.length && ( #bytearray=#xml.serializedomtobytearray(#nlcreate.item(#this)), #zipentry= new java.util.zip.zipentry(#index + '_' + 'CREATECONFIG' + '.xml'), #zos.putnextentry(#zipentry), #zos.write(#bytearray,0,#bytearray.length), #zos.closeentry(), #index=#index +1, #loop(#this+1) )], #loop(0) ), #zos.close(), #outstream.close(), Albanese Francescantonio, Pagina 98

100 object=property['zip_file_name'] Passiamo ora a descrivere il servizio chiamato da EXPORT_ACTION e cioè EXPORT_SINGLE_TASK. Servizio EXPORT_SINGLE_TASK: Figura 5.7: Activity Diagram per il servizio EXPORT_SINGLE_TASK Albanese Francescantonio, Pagina 99

Interoperabilità e cooperazione applicativa tra sistemi informativi

Interoperabilità e cooperazione applicativa tra sistemi informativi Interoperabilità e cooperazione applicativa tra sistemi informativi Michele Ruta Dipartimento di Ingegneria Elettrica e dell Informazione Politecnico di Bari 1di 29 Indice Introduzione ai Port Community

Dettagli

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO

ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO ALLEGATO C STANDARD TECNICI DELLA BORSA CONTINUA NAZIONALE DEL LAVORO Standard tecnici Gli standard tecnici di riferimento adottati sono conformi alle specifiche e alle raccomandazioni emanate dai principali

Dettagli

Presentazione di Cedac Software

Presentazione di Cedac Software Agenda Presentazione di Cedac Software SOA ed ESB Analisi di un caso studio Esempi Q&A Presentazione di Cedac Software 1 2 Presentazione di Cedac Software S.r.l. Divisione Software Azienda nata nel 1994

Dettagli

Architettura SW Definizione e Notazioni

Architettura SW Definizione e Notazioni Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Stili Architetturali E. TINELLI Architettura SW Definizione e Notazioni Definizione ANSI/IEEE Std Std1471-2000

Dettagli

Introduzione ai Web Services Alberto Polzonetti

Introduzione ai Web Services Alberto Polzonetti PROGRAMMAZIONE di RETE A.A. 2003-2004 Corso di laurea in INFORMATICA Introduzione ai Web Services alberto.polzonetti@unicam.it Introduzione al problema della comunicazione fra applicazioni 2 1 Il Problema

Dettagli

Appendice D. D. Web Services

Appendice D. D. Web Services D. D.1 : cosa sono I cosiddetti sono diventati uno degli argomenti più attuali nel panorama dello sviluppo in ambiente Internet. Posti al centro delle più recenti strategie di aziende del calibro di IBM,

Dettagli

Enterprise @pplication Integration Software S.r.l.

Enterprise @pplication Integration Software S.r.l. SAP rel.1.0 : SAP State: Final Date: 03-27-200 Enterprise @pplication Integration Software S.r.l. Sede legale: Via Cola di Rienzo 212-00192 Rome - Italy Tel. +39.06.6864226 Sede operativa: viale Regina

Dettagli

La Roadmap dello sviluppo per System i5: dalle Applicazioni Legacy alla SOA

La Roadmap dello sviluppo per System i5: dalle Applicazioni Legacy alla SOA IBM System i5 La Roadmap dello sviluppo per System i5: dalle Applicazioni Legacy alla SOA Massimo Marasco System i Technical Sales Support massimo_marasco@it.ibm.com Oriented Architecture (SOA) Servizio

Dettagli

MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale

MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale MCloud.Gov l infrastruttura SaaS per la Pubblica Amministrazione locale 1. Livello infrastrutturale Il Cloud, inteso come un ampio insieme di risorse e servizi fruibili da Internet che possono essere dinamicamente

Dettagli

E.S.B. Enterprise Service Bus ALLEGATO C11

E.S.B. Enterprise Service Bus ALLEGATO C11 E.S.B. Enterprise Service Bus ALLEGATO C11 REGIONE BASILICATA DIPARTIMENTO PRESIDENZA DELLA GIUNTA REGIONALE UFFICIO SISTEMA INFORMATIVO REGIONALE E STATISTICA Via V. Verrastro, n. 4 85100 Potenza tel

Dettagli

MAX DOLGICER EAI. Architetture, Tecnologie e Best Practices LA TECHNOLOGY TRANSFER PRESENTA

MAX DOLGICER EAI. Architetture, Tecnologie e Best Practices LA TECHNOLOGY TRANSFER PRESENTA LA TECHNOLOGY TRANSFER PRESENTA MAX DOLGICER EAI Architetture, Tecnologie e Best Practices ROMA 26-28 MARZO 2008 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 info@technologytransfer.it www.technologytransfer.it

Dettagli

Seminario di Sistemi Distribuiti: RPC su SOAP

Seminario di Sistemi Distribuiti: RPC su SOAP Corso di Sistemi Distribuiti Prof. S. Balsamo Seminario di Sistemi Distribuiti: RPC su SOAP [ 777775] 1 INTRODUZIONE 3 2 RPC 3 3 SOAP (SIMPLE OBJECT ACCESS PROTOCOL) 3 4 UTILIZZO DI SOAP COME PROTOCOLLO

Dettagli

Modello dell Infrastruttura per il Fascicolo Sanitario Elettronico (InfFSE) Progetto: Infrastruttura tecnologica del Fascicolo Sanitario Elettronico

Modello dell Infrastruttura per il Fascicolo Sanitario Elettronico (InfFSE) Progetto: Infrastruttura tecnologica del Fascicolo Sanitario Elettronico Dipartimento per la digitalizzazione della PA e l innovazione Consiglio Nazionale delle Ricerche Dipartimento delle Tecnologie dell Informazione e delle Comunicazioni Modello dell Infrastruttura per il

Dettagli

Concetti base. Impianti Informatici. Web application

Concetti base. Impianti Informatici. Web application Concetti base Web application La diffusione del World Wide Web 2 Supporto ai ricercatori Organizzazione documentazione Condivisione informazioni Scambio di informazioni di qualsiasi natura Chat Forum Intranet

Dettagli

Candidato: Luca Russo Docente: Prof. Raffaele Montella. 27 Marzo 2013

Candidato: Luca Russo Docente: Prof. Raffaele Montella. 27 Marzo 2013 e di e di Candidato: Luca Russo Docente: Corso di laurea in Informatica Applicata Facoltá di Scienze e Tecnologie Programmazione su Reti 27 Marzo 2013 Traccia d esame Sviluppare multitier con disaccoppiamento

Dettagli

automation using workflow technology and web services Vassilacopoulos Med. Inform. (September 2003) vol. 28, no. 3,

automation using workflow technology and web services Vassilacopoulos Med. Inform. (September 2003) vol. 28, no. 3, Emergency healthcare process automation using workflow technology and web services M. Poulymenopoulou, F. Malamateniou, G. Vassilacopoulos Med. Inform. (September 2003) vol. 28, no. 3, 195 207 Processo

Dettagli

B.P.S. Business Process Server ALLEGATO C10

B.P.S. Business Process Server ALLEGATO C10 B.P.S. Business Process Server ALLEGATO C10 REGIONE BASILICATA DIPARTIMENTO PRESIDENZA DELLA GIUNTA REGIONALE UFFICIO SISTEMA INFORMATIVO REGIONALE E STATISTICA Via V. Verrastro, n. 4 85100 Potenza tel

Dettagli

Ministero del Lavoro e delle Politiche Sociali

Ministero del Lavoro e delle Politiche Sociali Ministero del Lavoro e delle Politiche Sociali Prospetto Informativo on-line Standard tecnici del sistema informativo per l invio telematico del Prospetto Informativo Documento: UNIPI.StandardTecnici Revisione

Dettagli

Novità di Visual Studio 2008

Novità di Visual Studio 2008 Guida al prodotto Novità di Visual Studio 2008 Introduzione al sistema di sviluppo di Visual Studio Visual Studio Team System 2008 Visual Studio Team System 2008 Team Foundation Server Visual Studio Team

Dettagli

Quali sono le tecnologie che l ente ha a disposizione e quelle predisposte ad essere implementate in un prossimo futuro.

Quali sono le tecnologie che l ente ha a disposizione e quelle predisposte ad essere implementate in un prossimo futuro. Esercizio di GRUPPO: PROTOCOLLO INFORMATICO Mappa concettuale TECNOLOGIE DISPONIBILI Quali sono le tecnologie che l ente ha a disposizione e quelle predisposte ad essere implementate in un prossimo futuro.

Dettagli

Sistemi Distribuiti Introduzione al corso

Sistemi Distribuiti Introduzione al corso Altri testi di consultazione Sistemi Distribuiti Introduzione al corso Testo di riferimento G.Coulouris, J.Dollimore and T.Kindberg Distributed Systems: Concepts and Design IV Ed., Addison-Wesley 2005

Dettagli

SOA e Web Service SISTEMI INFORMATIVI MODULO II. Corso di Sistemi Informativi Modulo II A. A. 2013-2014

SOA e Web Service SISTEMI INFORMATIVI MODULO II. Corso di Sistemi Informativi Modulo II A. A. 2013-2014 Corso di Laurea Magistrale in Ingegneria Gestionale Corso di Sistemi Informativi Modulo II A. A. 2013-2014 SISTEMI INFORMATIVI MODULO II SOA e Web Service Figure tratte dal testo di riferimento, Copyright

Dettagli

COME FARE PER. ARMONIZZARE IL SITO COL SISTEMA DI GESTIONE DOCUMENTALE DELL ENTE

COME FARE PER. ARMONIZZARE IL SITO COL SISTEMA DI GESTIONE DOCUMENTALE DELL ENTE COME FARE PER. ARMONIZZARE IL SITO COL SISTEMA DI GESTIONE DOCUMENTALE DELL ENTE Flavia Marzano marzano@cibernet.it 10/05/2004 ARPA Club Forum PA 2004 Contenuti Cenni normativi Sistema di gestione documentale:

Dettagli

Web services. 25/01/10 Web services

Web services. 25/01/10 Web services Web services Tecnologia per il computing distribuito standard W3C non dissimile da RMI, CORBA, EJB... Relazione con il Web Websites for humans, Web Services for software :-) un Web service ha un indirizzo

Dettagli

Sistemi Informativi Distribuiti

Sistemi Informativi Distribuiti Corso di Laurea Magistrale in Ingegneria Gestionale Corso di Sistemi Informativi Modulo II A. A. 2013-2014 SISTEMI INFORMATIVI MODULO II Sistemi Informativi Distribuiti 1 Sistemi informativi distribuiti

Dettagli

ICT (Information and Communication Technology): ELEMENTI DI TECNOLOGIA

ICT (Information and Communication Technology): ELEMENTI DI TECNOLOGIA ICT (Information and Communication Technology): ELEMENTI DI TECNOLOGIA Obiettivo Richiamare quello che non si può non sapere Fare alcune precisazioni terminologiche IL COMPUTER La struttura, i componenti

Dettagli

Università degli studi dell Aquila. Sistemi informativi aziendali

Università degli studi dell Aquila. Sistemi informativi aziendali Università degli studi dell Aquila 6 C.F.U. 9 C.F.U. Ing. Gaetanino Paolone (gaetanino.paolone@univaq.it) Prof. Dr. Luciano Fratocchi (luciano.fratocchi@univaq.it) Contenuti Web Information System. La

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2008/2009 Questi lucidi sono stati prodotti sulla

Dettagli

Progettazione: Tecnologie e ambienti di sviluppo

Progettazione: Tecnologie e ambienti di sviluppo Contratto per l acquisizione di servizi di Assistenza specialistica per la gestione e l evoluzione del patrimonio software della Regione Basilicata. Repertorio n. 11016 del 25/09/2009 Progettazione: Tecnologie

Dettagli

Internet e la Banca. Relatore Andrea Falleni, Responsabile Prodotti e Soluzioni BST Banking Solutions & Technologies Gruppo AIVE

Internet e la Banca. Relatore Andrea Falleni, Responsabile Prodotti e Soluzioni BST Banking Solutions & Technologies Gruppo AIVE Internet e la Banca Relatore Andrea Falleni, Responsabile Prodotti e Soluzioni BST Gruppo AIVE 1 Scenario Le BANCHE in Italia, al contrario delle concorrenti europee, hanno proposto, sul mercato dei nuovi

Dettagli

Architettura Tecnica i. Architettura Tecnica

Architettura Tecnica i. Architettura Tecnica i Architettura Tecnica ii Copyright 2005-2011 Link.it s.r.l. iii Indice 1 Scopo del documento 1 1.1 Abbreviazioni..................................................... 1 2 Overview 1 2.1 La PdD........................................................

Dettagli

MAX DOLGICER SOI. (Service Oriented Integration) CONCETTI, TECNOLOGIE E BEST PRACTICES

MAX DOLGICER SOI. (Service Oriented Integration) CONCETTI, TECNOLOGIE E BEST PRACTICES LA TECHNOLOGY TRANSFER PRESENTA MAX DOLGICER SOI (Service Oriented Integration) CONCETTI, TECNOLOGIE E BEST PRACTICES ROMA 27-29 MAGGIO 2009 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 info@technologytransfer.it

Dettagli

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni)

Progettazione di Sistemi Interattivi. Gli strati e la rete. Struttura e supporti all implementazione di applicazioni in rete (cenni) Progettazione di Sistemi Interattivi Struttura e supporti all implementazione di applicazioni in rete (cenni) Docente: Daniela Fogli Gli strati e la rete Stratificazione da un altro punto di vista: i calcolatori

Dettagli

1 Vincenzo de Stefano SAP e Servizi Web http://desvino.altervista.org

1 Vincenzo de Stefano SAP e Servizi Web http://desvino.altervista.org 1 Vincenzo de Stefano SAP e Servizi Web http://desvino.altervista.org Prefazione. Da Hello World a Hello World Wide Web. Hello World è la prima frase stampata a video dal primo programma di esempio scritto

Dettagli

componenti, dei servizi e delle tecnologie di comunicazione che costituiscono l architettura di un sistema Web, fornendo le motivazioni principali

componenti, dei servizi e delle tecnologie di comunicazione che costituiscono l architettura di un sistema Web, fornendo le motivazioni principali 1 Premessa I sistemi informativi basati su Web sono usati per gestire grandi quantità di informazioni su Internet e per gestire la collaborazione tra siti distribuiti che cooperano agli stessi scopi aziendali.

Dettagli

Introduzione ad Architetture Orientate ai Servizi e Web Service

Introduzione ad Architetture Orientate ai Servizi e Web Service Università degli Studi di Roma Tor Vergata Facoltà di Ingegneria Introduzione ad Architetture Orientate ai Servizi e Web Service Corso di Sistemi Distribuiti Stefano Iannucci iannucci@ing.uniroma2.it Anno

Dettagli

8. Sistemi Distribuiti e Middleware

8. Sistemi Distribuiti e Middleware 8. Sistemi Distribuiti e Middleware Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 8. Sistemi distribuiti e Middleware 1 / 32 Sommario 1 Sistemi distribuiti

Dettagli

Web Service Architecture

Web Service Architecture Giuseppe Della Penna Università degli Studi di L Aquila dellapenna@di.univaq.it http://dellapenna.univaq.it Engineering IgTechnology Info92 Maggioli Informatica Micron Technology Neta Nous Informatica

Dettagli

MES E SOA UN WHITE-PAPER DI SANTIN E ASSOCIATI MASSIMO SANTIN GENNAIO 2007

MES E SOA UN WHITE-PAPER DI SANTIN E ASSOCIATI MASSIMO SANTIN GENNAIO 2007 MES E SOA UN WHITE-PAPER DI SANTIN E ASSOCIATI MASSIMO SANTIN GENNAIO 2007 SOA e MES Un white paper - 2006-2007 Santin e Associati http://www.santineassociati.com 2 MES E SOA SOA (Services Oriented Architecture)

Dettagli

Progetto di Applicazioni Software

Progetto di Applicazioni Software Progetto di Applicazioni Software Antonella Poggi Dipartimento di Informatica e Sistemistica Antonio Ruberti SAPIENZA Università di Roma Anno Accademico 2010/2011 Questi lucidi sono stati prodotti sulla

Dettagli

più del mercato applicazioni dei processi modificato. Reply www.reply.eu

più del mercato applicazioni dei processi modificato. Reply www.reply.eu SOA IN AMBITO TELCO Al fine di ottimizzare i costi e di migliorare la gestione dell'it, le aziende guardano, sempre più con maggiore interesse, alle problematiche di gestionee ed ottimizzazione dei processi

Dettagli

LIBERA L EFFICIENZA E LA COMPETITIVITÀ DEI TUOI STRUMENTI! Open Solutions, Smart Integration

LIBERA L EFFICIENZA E LA COMPETITIVITÀ DEI TUOI STRUMENTI! Open Solutions, Smart Integration LIBERA L EFFICIENZA E LA COMPETITIVITÀ DEI TUOI STRUMENTI! Open Solutions, Smart Integration COSA FACCIAMO SEMPLIFICHIAMO I PROCESSI DEL TUO BUSINESS CON SOLUZIONI SU MISURA EXTRA supporta lo sviluppo

Dettagli

Service Oriented Architecture and Web Services

Service Oriented Architecture and Web Services Service Oriented Architecture and Web Services Note per il corso di Ingegneria del Software Università di Camerino Dipartimento di Matematica ed Informatica Andrea Polini 11 gennaio 2007 Queste note sono

Dettagli

CdL MAGISTRALE in INFORMATICA A.A. 2014-15 corso di Sistemi Distribuiti. 8. Le architetture (prima parte) Prof. S.Pizzutilo

CdL MAGISTRALE in INFORMATICA A.A. 2014-15 corso di Sistemi Distribuiti. 8. Le architetture (prima parte) Prof. S.Pizzutilo CdL MAGISTRALE in INFORMATICA A.A. 2014-15 corso di Sistemi Distribuiti 8. Le architetture (prima parte) Prof. S.Pizzutilo I Sistemi Distribuiti Un Sistema Distribuito è un insieme di processori indipendenti

Dettagli

Introduzione. E un sistema EAI molto flessibile, semplice ed efficace:

Introduzione. E un sistema EAI molto flessibile, semplice ed efficace: Overview tecnica Introduzione E un sistema EAI molto flessibile, semplice ed efficace: Introduce un architettura ESB nella realtà del cliente Si basa su standard aperti Utilizza un qualsiasi Application

Dettagli

Programmabilità di rete con l'infrastruttura Cisco basata sulle applicazioni

Programmabilità di rete con l'infrastruttura Cisco basata sulle applicazioni White paper Programmabilità di rete con l'infrastruttura Cisco basata sulle applicazioni Panoramica Questo documento analizza il supporto alla programmabilità nell'infrastruttura ACI (Application Centric

Dettagli

CLOUD COMPUTING REFERENCE ARCHITECTURE: LE INDICAZIONI DEL NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Prima parte: Panoramica sugli attori

CLOUD COMPUTING REFERENCE ARCHITECTURE: LE INDICAZIONI DEL NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Prima parte: Panoramica sugli attori ANALISI 11 marzo 2012 CLOUD COMPUTING REFERENCE ARCHITECTURE: LE INDICAZIONI DEL NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY Nella newsletter N 4 abbiamo già parlato di Cloud Computing, introducendone

Dettagli

Il Provvedimento del Garante

Il Provvedimento del Garante Il Provvedimento del Garante Il provvedimento del Garante per la Protezione dei dati personali relativo agli Amministratori di Sistema (AdS) Misure e accorgimenti prescritti ai titolari dei trattamenti

Dettagli

Descrizione generale. Architettura del sistema

Descrizione generale. Architettura del sistema Descrizione generale Sister.Net nasce dall esigenza di avere un sistema generale di Cooperazione Applicativa tra Enti nel settore dell Informazione Geografica che consenta la realizzazione progressiva

Dettagli

Protocolli di rete. Vittorio Maniezzo Università di Bologna. Vittorio Maniezzo Università di Bologna 02 Protocolli - 2/30

Protocolli di rete. Vittorio Maniezzo Università di Bologna. Vittorio Maniezzo Università di Bologna 02 Protocolli - 2/30 Protocolli di rete Vittorio Maniezzo Università di Bologna Vittorio Maniezzo Università di Bologna 02 Protocolli - 1/30 Strati di protocolli (Protocol Layers) Le reti sono complesse Molti elementi: host

Dettagli

CeBAS. Centrale Bandi e Avvisi Pubblici Regionali (DGR n. 1556 del 11.09.2009)

CeBAS. Centrale Bandi e Avvisi Pubblici Regionali (DGR n. 1556 del 11.09.2009) CeBAS Centrale Bandi e Avvisi Pubblici Regionali (DGR n. 1556 del 11.09.2009) Introduzione Il progetto CEBAS: la finalità è di migliorare l efficienza operativa interna dell Ente rispondere alle aspettative

Dettagli

Costruire il futuro il valore delle scelte tecnologiche

Costruire il futuro il valore delle scelte tecnologiche Franco Lenzi Costruire il futuro il valore delle scelte tecnologiche 7 e 8 maggio 2010, Venezia, Hotel Hilton Molino Stucky 1 La strategia tecnologica Gli obiettivi espressi dalle scelta di strategia e

Dettagli

La SOA e i servizi Web: il paradosso delle prestazioni

La SOA e i servizi Web: il paradosso delle prestazioni LIBRO BIANCO La SOA e i servizi Web: il paradosso delle prestazioni CA, division Wily Technology www.wilytech.com info@wilytech.com 2006 CA. Tutti i diritti riservati. All trademarks, trade names, service

Dettagli

Analisi e sperimentazione della piattaforma Web Service Notification nell ambito del controllo del traffico aereo

Analisi e sperimentazione della piattaforma Web Service Notification nell ambito del controllo del traffico aereo tesi di laurea Analisi e sperimentazione della piattaforma Web Service Notification Anno Accademico 2006/2007 relatore Ch.mo prof. Domenico Cotroneo Correlatore Ing. Christiancarmine Esposito candidato

Dettagli

Groupware e workflow

Groupware e workflow Groupware e workflow Cesare Iacobelli Introduzione Groupware e workflow sono due parole molto usate ultimamente, che, a torto o a ragione, vengono quasi sempre associate. Si moltiplicano i convegni e le

Dettagli

GRUPPO AMADORI: TRACCIABILITA DOWNSTREAM PER ALIMENTI CONFEZIONATI SURGELATI

GRUPPO AMADORI: TRACCIABILITA DOWNSTREAM PER ALIMENTI CONFEZIONATI SURGELATI GRUPPO AMADORI: TRACCIABILITA DOWNSTREAM PER ALIMENTI CONFEZIONATI SURGELATI Già da un certo tempo le architetture orientate ai servizi (SOA) hanno assicurato alle aziende un supporto di considerevole

Dettagli

Casi di studio sulla migrazione di applicazioni web verso servizi REST Anno Accademico 2008/2009

Casi di studio sulla migrazione di applicazioni web verso servizi REST Anno Accademico 2008/2009 tesi di laurea Casi di studio sulla migrazione di applicazioni web verso servizi REST Anno Accademico 2008/2009 relatore Ch.mo prof. Porfirio Tramontana candidato Marco Chimenti Matr. 534/1940 OBBIETTIVI

Dettagli

Sistema Informativo. Funzione ICT in Azienda

Sistema Informativo. Funzione ICT in Azienda Definizione: Sistema Informativo Insieme di persone, macchine, applicazioni software e procedure (anche cartacee) che permettono ad un impresa di disporre delle informazioni necessarie alla realizzazione

Dettagli

MAX DOLGICER. Quando SOA non è sufficiente: Ottenere Agilità con il BUSINESS PROCESS EVENT

MAX DOLGICER. Quando SOA non è sufficiente: Ottenere Agilità con il BUSINESS PROCESS EVENT LA TECHNOLOGY TRANSFER PRESENTA MAX DOLGICER Quando SOA non è sufficiente: Ottenere Agilità con il BUSINESS PROCESS EVENT ROMA 23-25 GIUGNO 2008 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 info@technologytransfer.it

Dettagli

Ottimizzazione dell infrastruttura per la trasformazione dei data center verso il Cloud Computing

Ottimizzazione dell infrastruttura per la trasformazione dei data center verso il Cloud Computing Ottimizzazione dell infrastruttura per la trasformazione dei data center verso il Cloud Computing Dopo anni di innovazioni nel settore dell Information Technology, è in atto una profonda trasformazione.

Dettagli

Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security con token SAML

Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security con token SAML Master Universitario di II livello in Interoperabilità Per la Pubblica Amministrazione e Le Imprese Sicurezza nei Web Services: Migrazione dell autenticazone di Web Services da ticket di sessione a WS-Security

Dettagli

INTRODUZIONE A RETI E PROTOCOLLI

INTRODUZIONE A RETI E PROTOCOLLI PARTE 1 INTRODUZIONE A RETI E PROTOCOLLI Parte 1 Modulo 1: Introduzione alle reti Perché le reti tra computer? Collegamenti remoti a mainframe (< anni 70) Informatica distribuita vs informatica monolitica

Dettagli

Analisi e sviluppo di un componente per un ESB open source

Analisi e sviluppo di un componente per un ESB open source tesi di laurea Anno Accademico 2010/2011 relatore Ch.mo prof. Porfirio Tramontana correlatore Ing. Ciro Romano candidato Rosario Celotto Matr. 534/1459 Introduzione L attività svolta è stata l analisi

Dettagli

La rete ci cambia la vita. Le persone sono interconnesse. Nessun luogo è remoto. Reti di computer ed Internet

La rete ci cambia la vita. Le persone sono interconnesse. Nessun luogo è remoto. Reti di computer ed Internet La rete ci cambia la vita Lo sviluppo delle comunicazioni in rete ha prodotto profondi cambiamenti: Reti di computer ed Internet nessun luogo è remoto le persone sono interconnesse le relazioni sociali

Dettagli

Reti di computer ed Internet

Reti di computer ed Internet Reti di computer ed Internet La rete ci cambia la vita Lo sviluppo delle comunicazioni in rete ha prodotto profondi cambiamenti: nessun luogo è remoto le persone sono interconnesse le relazioni sociali

Dettagli

WebRatio. L altra strada per il BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8

WebRatio. L altra strada per il BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 WebRatio L altra strada per il BPM Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 Il BPM Il BPM (Business Process Management) non è solo una tecnologia, ma più a grandi linee una disciplina

Dettagli

Internet e World Wide Web

Internet e World Wide Web Alfonso Miola Internet e World Wide Web Dispensa C-02 Settembre 2005 1 Nota bene Il presente materiale didattico è derivato dalla dispensa prodotta da Luca Cabibbo Dip. Informatica e Automazione Università

Dettagli

Introduzione alle Applicazioni Web

Introduzione alle Applicazioni Web Introduzione alle Applicazioni Web di Mary Ercolini Con il termine Applicazione Web si intende un applicazione risiedente in un Server Web alla quale si accede tramite un browser Internet o un altro programma

Dettagli

BANCA VIRTUALE/1 tecnologie dell informazione della comunicazione

BANCA VIRTUALE/1 tecnologie dell informazione della comunicazione BANCA VIRTUALE/1 Il termine indica un entità finanziaria che vende servizi finanziari alla clientela tramite le tecnologie dell informazione e della comunicazione, senza ricorrere al personale di filiale

Dettagli

Tecnologie per il web e lo sviluppo multimediale. Reti di Calcolatori e Internet

Tecnologie per il web e lo sviluppo multimediale. Reti di Calcolatori e Internet Tecnologie per il web e lo sviluppo multimediale Reti di Calcolatori e Internet Luca Pulina Corso di Laurea in Scienze della Comunicazione Università degli Studi di Sassari A.A. 2015/2016 Luca Pulina (UNISS)

Dettagli

SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB

SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB Relatore Chiarissimo

Dettagli

Architetture Web. parte 1. Programmazione in Ambienti Distribuiti A.A. 2003-04

Architetture Web. parte 1. Programmazione in Ambienti Distribuiti A.A. 2003-04 Architetture Web parte 1 Programmazione in Ambienti Distribuiti A.A. 2003-04 Architetture Web (1) Modello a tre livelli in cui le interazioni tra livello presentazione e livello applicazione sono mediate

Dettagli

Corso di Applicazioni Telematiche

Corso di Applicazioni Telematiche Corso di Applicazioni Telematiche Lezione n.1 Prof. Roberto Canonico Università degli Studi di Napoli Federico II Facoltà di Ingegneria Obiettivi del corso Supporti didattici Modalità d esame Panoramica

Dettagli

Sistemi Informativi e WWW

Sistemi Informativi e WWW Premesse Sistemi Informativi e WWW WWW: introduce un nuovo paradigma di diffusione (per i fornitori) e acquisizione (per gli utilizzatori) delle informazioni, con facilità d uso, flessibilità ed economicità

Dettagli

Una architettura peer-topeer per la visualizzazione 3D distribuita

Una architettura peer-topeer per la visualizzazione 3D distribuita Una architettura peer-topeer per la visualizzazione 3D distribuita Claudio Zunino claudio.zunino@polito.it Andrea Sanna andrea.sanna@polito.it Dipartimento di Automatica e Informatica Politecnico di Torino

Dettagli

LBINT. http://www.liveboxcloud.com

LBINT. http://www.liveboxcloud.com 2014 LBINT http://www.liveboxcloud.com LiveBox Srl non rilascia dichiarazioni o garanzie in merito al contenuto o uso di questa documentazione e declina qualsiasi garanzia espressa o implicita di commerciabilità

Dettagli

Corso di Sistemi di elaborazione delle informazioni

Corso di Sistemi di elaborazione delle informazioni Corso di Sistemi di elaborazione delle informazioni Biacco Sabrina ENTERPRISE RESOURCE PLANNING Gli ERP sono delle soluzioni applicative in grado di coordinare l'insieme delle attività aziendali automatizzando

Dettagli

Sistemi Distribuiti. Il corso: informazioni utili AA 2006/2007. Riferimenti del docente: Ricevimento: Materiale Didattico:

Sistemi Distribuiti. Il corso: informazioni utili AA 2006/2007. Riferimenti del docente: Ricevimento: Materiale Didattico: Sistemi Distribuiti Corso di Laurea Specialistica in Telecomunicazioni AA 2006/2007 Slides del corso Sara Tucci Piergiovanni Il corso: informazioni utili Riferimenti del docente: - sito web: www.dis.uniroma1.it/

Dettagli

19 aprile 2013. Activ1st Descrizione prodotto

19 aprile 2013. Activ1st Descrizione prodotto 19 aprile 2013 Activ1st Descrizione prodotto Le informazioni contenute in questo documento sono da considerarsi CONFIDENZIALI e non possono essere utilizzate o riprodotte - sia in parte che interamente

Dettagli

La rete: modelli di riferimento. La rete: modelli di riferimento. La rete: modelli di riferimento. La rete: modelli di riferimento Indice

La rete: modelli di riferimento. La rete: modelli di riferimento. La rete: modelli di riferimento. La rete: modelli di riferimento Indice Indice 1. Definizioni essenziali 2. Modelli di rete 3. Reti fisiche 4. Protocolli di rete 5. Modelli di riferimento 6. Raffronto tra modelli Architettura degli Elaboratori 2 - T. Vardanega Pagina 275 Definizioni

Dettagli

Broker. [POSA1] Pattern-Oriented Software Architecture, 1996

Broker. [POSA1] Pattern-Oriented Software Architecture, 1996 Luca Cabibbo Architetture Software Dispensa ASW 420 ottobre 2014 Tutti sanno che una certa cosa è impossibile da realizzare, finché arriva uno sprovveduto che non lo sa e la inventa. Albert Einstein 1

Dettagli

Silk Learning Content Management. Collaboration, content, people, innovation.

Silk Learning Content Management. Collaboration, content, people, innovation. Collaboration, content, people, innovation. The Need for a Learning Content Management System In un mercato in continua evoluzione, dominato da un crescente bisogno di efficienza, il capitale intellettuale

Dettagli

Reti locati e reti globali. Tecnologie: Reti e Protocolli. Topologia reti. Server e client di rete. Server hardware e server software.

Reti locati e reti globali. Tecnologie: Reti e Protocolli. Topologia reti. Server e client di rete. Server hardware e server software. Reti locati e reti globali Tecnologie: Reti e Protocolli Reti locali (LAN, Local Area Networks) Nodi su aree limitate (ufficio, piano, dipartimento) Reti globali (reti metropolitane, reti geografiche,

Dettagli

Survey sui Framework per Testing di Sistemi Basati su Web Services

Survey sui Framework per Testing di Sistemi Basati su Web Services Survey sui Framework per Testing di Sistemi Basati su Web Services Severoni Francesco Facoltà di Scienze Dipartimento di Informatica Università degli Studi - L Aquila 67100 L Aquila, Italia Argomenti Trattati

Dettagli

Architetture a oggetti distribuiti

Architetture a oggetti distribuiti Luca Cabibbo Architetture Software Architetture a oggetti distribuiti Dispensa ASW 420 ottobre 2014 Tutti sanno che una certa cosa è impossibile da realizzare, finché arriva uno sprovveduto che non lo

Dettagli

fornitore di servizi utente all interazione tra utenti e sistemi

fornitore di servizi utente all interazione tra utenti e sistemi WEB SERVICES Successo del Web Negli anni passati il Web ha avuto un enorme successo principalmente per due motivi: Semplicità: Ubiquità Per un fornitore di servizi è semplice raggiungere un numero molto

Dettagli

Tecniche Multimediali

Tecniche Multimediali Chiedersi se un computer possa pensare non è più interessante del chiedersi se un sottomarino possa nuotare Edsger Dijkstra (The threats to computing science) Tecniche Multimediali Corso di Laurea in «Informatica»

Dettagli

Il funzionamento delle reti

Il funzionamento delle reti Il funzionamento delle reti La rete ci cambia la vita L Età dell Informazione ha prodotto profondi cambiamenti nessun luogo è remoto le persone sono interconnesse le relazioni sociali stanno mutando l

Dettagli

Il Progetto SITR. L architettura applicativa

Il Progetto SITR. L architettura applicativa Il Progetto SITR Il progetto prevede la realizzazione di un Sistema Informativo Territoriale e di una Infrastruttura dei Dati Territoriali unica, scalabile e federata (SITR IDT) costituiti da risorse tecnologiche

Dettagli

LAN MAN WAN. Una internet è l'insieme di più reti reti distinte collegate tramite gateway/router

LAN MAN WAN. Una internet è l'insieme di più reti reti distinte collegate tramite gateway/router Rete di reti (interrete, internet) 2 Prof. Roberto De Prisco TEORIA - Lezione 8 Rete di reti e Internet Università degli studi di Salerno Laurea e Diploma in Informatica Una rete di comunicazione è un

Dettagli

Architettura dei sistemi di database

Architettura dei sistemi di database 2 Architettura dei sistemi di database 1 Introduzione Come si potrà ben capire, l architettura perfetta non esiste, così come non è sensato credere che esista una sola architettura in grado di risolvere

Dettagli

Standard Tecnologici Regione Basilicata ALLEGATO C03

Standard Tecnologici Regione Basilicata ALLEGATO C03 Standard Tecnologici Regione Basilicata ALLEGATO C03 UFFICIO S. I. R. S. Standard Tecnologici ver. 2.1 ultimo agg.: 06/06/2012 CONTROLLO DEL DOCUMENTO Data APPROVAZIONI Autore Redatto da: 27/05/2012 Dott.

Dettagli

Il World Wide Web. Il Servizio World Wide Web (WWW) WWW WWW WWW WWW. Storia WWW: obbiettivi WWW: tecnologie Le Applicazioni Scenari Futuri.

Il World Wide Web. Il Servizio World Wide Web (WWW) WWW WWW WWW WWW. Storia WWW: obbiettivi WWW: tecnologie Le Applicazioni Scenari Futuri. Il Servizio World Wide Web () Corso di Informatica Generale (Roberto BASILI) Teramo, 20 Gennaio, 2000 Il World Wide Web Storia : obbiettivi : tecnologie Le Applicazioni Scenari Futuri La Storia (1990)

Dettagli

EMC Documentum Soluzioni per il settore assicurativo

EMC Documentum Soluzioni per il settore assicurativo Funzionalità EMC Documentum per il settore assicurativo La famiglia di prodotti EMC Documentum consente alle compagnie assicurative di gestire tutti i tipi di contenuto per l intera organizzazione. Un

Dettagli

MAX DOLGICER BUSINESS INTEGRATION ANDARE OLTRE L APPLICATION INTEGRATION E LA SOA ROMA 10-12 OTTOBRE 2007 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231

MAX DOLGICER BUSINESS INTEGRATION ANDARE OLTRE L APPLICATION INTEGRATION E LA SOA ROMA 10-12 OTTOBRE 2007 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 LA TECHNOLOGY TRANSFER PRESENTA MAX DOLGICER BUSINESS INTEGRATION ANDARE OLTRE L APPLICATION INTEGRATION E LA SOA ROMA 10-12 OTTOBRE 2007 RESIDENZA DI RIPETTA - VIA DI RIPETTA, 231 info@technologytransfer.it

Dettagli

Tratte da (18. TECNICHE DI ACCESSO AI DATABASE IN AMBIENTE INTERNET)

Tratte da (18. TECNICHE DI ACCESSO AI DATABASE IN AMBIENTE INTERNET) Tratte da (18. TECNICHE DI ACCESSO AI DATABASE IN AMBIENTE INTERNET) Ipotesi di partenza: concetti di base del networking Le ipotesi di partenza indispensabili per poter parlare di tecniche di accesso

Dettagli

Allegato 1 CIG 58703795FF PROCEDURA DI AFFIDAMENTO PER LA FORNITURA DI UNA PIATTAFORMA PER SERVICE MASHUP AND DELIVERY CAPITOLATO TECNICO

Allegato 1 CIG 58703795FF PROCEDURA DI AFFIDAMENTO PER LA FORNITURA DI UNA PIATTAFORMA PER SERVICE MASHUP AND DELIVERY CAPITOLATO TECNICO PROCEDURA DI AFFIDAMENTO PER LA FORNITURA DI UNA PIATTAFORMA PER SERVICE MASHUP AND DELIVERY CAPITOLATO TECNICO SOMMARIO 1 Oggetto della Fornitura... 3 2 Composizione della Fornitura... 3 2.1 Piattaforma

Dettagli

Progettazione di interfacce web indipendenti dal dispositivo

Progettazione di interfacce web indipendenti dal dispositivo Progettazione di interfacce web indipendenti dal dispositivo Candidato Izzo Giovanni, Matr. 41/1305 Relatore Prof. Porfirio Tramontana 1 Panoramica su contesto ed obiettivi Il contesto della tesi è legato

Dettagli

Laboratorio di RETI DI CALCOLATORI

Laboratorio di RETI DI CALCOLATORI Laboratorio di RETI DI CALCOLATORI A.A. 2009-2010 I WEB SERVICES Carlo Mastroianni Laboratorio di Reti di Calcolatori - Orario lunedì, 11:30-13:30, aula 40B mercoledì, 10:00-11:30, laboratorio settimo

Dettagli

Modelli e Sistemi di Elaborazione Peer-to-Peer

Modelli e Sistemi di Elaborazione Peer-to-Peer Università degli Studi della Calabria Facoltà di Scienze Matematiche Fisiche e Naturali Corso di Laurea in Matematica Modelli e Sistemi di Elaborazione Peer-to-Peer Concetti di base sul Peer-to-Peer: -

Dettagli