Università degli Studi di Roma "Tor Vergata" Facoltà di Scienze MFN

Save this PDF as:
 WORD  PNG  TXT  JPG

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Università degli Studi di Roma "Tor Vergata" Facoltà di Scienze MFN"

Transcript

1 Università degli Studi di Roma "Tor Vergata" Facoltà di Scienze MFN Corso di Laurea in Informatica Tesi di Laurea Analisi, progettazione e implementazione di un Infrastruttura di Comunicazione basata su Web services Relatore Chiar.mo Prof. Giorgio Gambosi Correlatore Dott. Marco Bianchi Candidato Antonio Mazza Matricola Anno accademico 2003/04

2 Alla famiglia e agli amici che mi danno la forza per non mollare 1

3 Indice Contesto formativo...13 Introduzione...13 Struttura della tesi...16 I - Scenario tecnologico e metodologico Web services Cosa sono i Web services Caratteristiche dei Web services Perché usare i Web services L architettura dei Web services I ruoli in un Web service Stack dei protocolli di un Web service Tecnologie dei Web services SOAP: il fulcro dell interoperabilità Cosa definisce SOAP La struttura di un messaggio SOAP SOAP con allegati Descrivere i Web services: WSDL Ricerca e pubblicazione dei Web services Sviluppo di Web services usando Java Apache Axis Caratteristiche principali di Axis Funzionalità e vantaggi di Axis L architettura di Axis Web service Deployment Descriptor (WSDD) Gestione degli allegati: Javabean Activation Framework

4 3. Modelli e processi di sviluppo Unified Process for EDUcational Caratteristiche e aspetti Ciclo di vita Catturare le informazioni del progetto: gli artefatti Extreme Programming I valori di XP Caratteristiche di XP Java e XP La filosofia dei tools in XP Automazione...48 Apache Ant Esecuzione di tests...50 JUnit...50 JMeter...51 TestMaker Localizzazione dei bugs...53 Log4J...53 II - Case study: un Infrastruttura di Comunicazione Analisi del contesto dell Infrastruttura di Comunicazione: scelte tecnologiche e metodologiche Introduzione al problema Il contesto: il sistema di catalogazione e condivisione Descrizione funzionale Assunzioni e attributi del sistema Architettura generale del sistema

5 4.2.4 Proiezione delle funzionalità sull architettura: realizzazione dei casi d uso Analisi tecnologica Java e i Web services Implementazione delle tecnologie e ambienti open source Analisi metodologica e processo di produzione del software: UP affiancato da XP Analisi dei requisiti, definizione dell architettura e pianificazione Introduzione alle iterazioni Definizione dei requisiti a partire dal contesto I casi d uso: l input per l analisi Requisiti non Funzionali e specifiche supplementari Business Rules Dal modello di analisi alla definizione dell architettura Definizione dei sottosistemi Definizione dell architettura Pattern Overview La gestione delle eccezioni Pianificazione dei tests Tests funzionali Test di performance e di scalabilità Piano di sviluppo del software Il sottosistema VirtualRepository dell Infrastruttura di Comunicazione Funzionalità e obbiettivi del sottosistema VirtualRepository Modello di analisi Definizione delle classi a partire dall architettura generale

6 6.4 Le dinamiche del sottosistema VirtualRepository: realizzazione dei casi d uso Rimuovi Metadata(LOM) da Catalogo DeleteLO Registra Metadata(LOM) su Catalogo InsertLO Modifica Metadata(LOM) su Catalogo Pianificazione ed esecuzione dei tests per il sottosistema VirtualRepository Tests funzionali Tests di performance e scalabilità Il sottosistema Repository dell Infrastruttura di Comunicazione Introduzione alle funzionalità del sottosistema Repository Il modello di analisi L architettura delle classi del sottosistema Repository Realizzazione dei casi d uso sulla base delle classi definite Richiedi lista LO su repository Predisponi Download LO su Repository Pianificazione, esecuzione e reports dei tests del sottosistema Repository Tests funzionali Tests di performance e scalabilità Il sottosistema Catalogue dell Infrastruttura di Comunicazione Analisi delle funzionalità Il modello di analisi Identificazione delle classi che definiscono l architettura Realizzazione dei casi d uso: collaborazioni tra gli oggetti Esegui query su Catalogo GetLO Scaricamento di un LO

7 8.5 Progettazione, esecuzione e reports dei tests Tests funzionali Tests di performance e scalabilità Integrazione, deployment e testing dell Infrastruttura di Comunicazione Integrazione e deployment Testing distribuito dell Infrastruttura di Comunicazione Tests funzionali del VirtualRepository Tests di performance e scalabilità del VRepository Tests funzionali del Repository Tests di performance e scalabilità del servizio Repository Testing delle funzionalità fornite alle Interfacce Tests di performance e scalabilità del servizio Catalogue Conclusioni Bibliografia

8 Indice delle figure Figura 1 - Un Web service permette l'accesso ad applicazioni usando tecnologie standard Figura 2 - Un semplice Web service Figura 3 - Messaggistica XML per i Web services Figura 4 - Modello operazionale dei Web services, visualizza ruoli e relazioni Figura 5 - Pila concettuale dei Web services Figura 6 - Struttura del messaggio SOAP Figura 7 - Rappresentazione concettuale del documento WSDL Figura 8 - Il cammino del Message sul Server. I cilindri piccoli rappresentano le handlers, quelli grandi, invece, rappresentano le chains Figura 9- Il cammino del Message sul Client. I cilindri piccoli rappresentano le handlers, quelli grandi, invece, rappresentano le chains Figura 10 - modello del ciclo di vita Figura 11 - ciclo di sviluppo Figura 12 - Casi d'uso relativi al sistema di condivisione e catalogazione di LO Figura 13 Componenti generali del sistema Figura 14 - Il sottosistema Catalogo Figura 15 - Architettura generale del sistema e collocazione dell'infrastruttura di Comunicazione Figura 16 - Sequence diagram relativo al caso d'uso DeployLO Figura 17 - Sequence diagram relativo al caso d'uso DeleteLO Figura 18 - Sequence diagram relativo al caso d'uso ModifyLO Figura 19 - Sequence diagram relativo al caso d'uso UpdateLOM Figura 20 - Sequence diagram relativo al caso d'uso QueryMetadata Figura 21 - Sequence diagram relativo al caso d'uso GetLO Figura 22 Architettura generale del sistema di catalogazione e condivisione Figura 23 - Diagramma dei casi d'uso dell'infrastruttura di Comunicazione... 75

9 Figura 24 - Analysis Classes Diagram Figura 25 - I sottosistemi dell'infrastruttura di Comunicazione Figura 26 - Architettura di comunicazione tra una componente e un Web service Figura 27 - La connessione tra i Web services e i componenti che ne implementano le funzionalità: i Connectors Figura 28 - Pattern overview dell'infrastruttura di Comunicazione Figura 29 - Struttura di un'eccezione nell'infrastruttura di Comunicazione Figura 30 - Casi d'uso relativi al sottosistema VirtualRepository Figura 31 - Analysis classes Diagram del sottosistema VirtualRepository Figura 32 - Classes Diagram del sottosistema VirtualRepository dell'infrastruttura di Comunicazione Figura 33 - I transfer objects utilizzati nel sottosistema VirtualRepository Figura 34 - Classes Diagram delle eccezioni del sottosistema VirtualRepository Figura 35 - Collaboration Diagram dell'operazione di rimozione di un LO dal Catalogo Figura 36 - Collaboration Diagram dell'operazione di inserimento di un LO sul Catalogo Figura 37 - Collaboration Diagram dell'operazione di aggiornamento dei LOM sul Catalogo.101 Figura 38 - Reports del sottosistema VirtualRepository Figura 39 Test di performance dell operazione di rimozione di un LO dal Catalogo del Web service VRepository (in locale) Figura 40 - Test di performance dell operazione di inserimento di un LO sul Catalogo del Web service VRepository (in locale) Figura 41 - Test di performance dell operazione di aggiornamento dei metadata (LOM) sul Catalogo del Web service VRepository (in locale) Figura 42 - Dettagli delle operazioni testate sul Web service(numero di volte eseguite, media del tempo in ms, minimo tempo, max tempo, percentuale di errore, numero ipotizzato di operazioni per secondo). (in locale) Figura 43 - Rappresentazione grafica della media, mediana, deviazione standard dei tempi impiegati nell eseguire le operazioni(300) e il numero di richieste per minuto relative al Web service VRepository. (in locale) Figura 44 - Rappresentazione grafica dei tempi impiegati nell eseguire le singole operazioni esposte dal Web service VRepository. (in locale)

10 Figura 45 - Diagramma dei casi d'uso che deve realizzare il sottosistema Repository dell'infrastruttura di Comunicazione Figura 46 - Analysis Classes Diagrams del sottosistema Repository Figura 47 - Classes Diagram del sottosistema Repository dell'infrastruttura di Comunicazione Figura 48 - Class Diagram che mette in risalto la gestione dello scaricamento di un LO Figura 49 - I TO del sottosistema Repository Figura 50 - Classes Diagram del RepositoryLocator Figura 51 - Classes Diagram delle eccezione del sottosistema Repository Figura 52 - Collaboration Diagram dell'operazione di restituzione della lista di LO presenti su un Repository Figura 53 - Collaboration Diagram dell'operazione di predispozizione dei parametri download sul Repository Figura 54 - Reports dell'esecuzione del test funzionale del sottosistema Repository Figura 55 - Test di performance dell operazione di restituzione della lista (10) di LO (id) del Web service Repository Figura 56 - Test di performance dell operazione di impostazione dei parametri per il download del Web service Repository Figura 57 - Test di performance dell operazione di scaricamento di un LO (dim: 11.2 MB) del Web service Repository Figura 58 - Dettagli delle operazioni testate sul Web service Repository (numero di volte eseguite, media del tempo in ms, minimo tempo, max tempo, percentuale di errore, numero ipotizzato di operazioni per secondo). (in locale) Figura 59 - Rappresentazione grafica della media, mediana, deviazione standard dei tempi impiegati nell eseguire le operazioni(150) e il numero di richieste per minuto relative al Web service Repository. (in locale) Figura 60 - Rappresentazione grafica dei tempi impiegati nell eseguire le singole operazioni esposte dal Web service Repository. (in locale) Figura 61 - I casi d'uso del sottosistema Catalogue Figura 62 - Analysis Classes Diagram del sottosistema Catalogue Figura 63 - Classes Diagram del sottosistema Catalogue

11 Figura 64 - I Transfer Objects del sottosistema Catalogue Figura 65 - Le eccezioni del sottosistema Catalogue Figura 66 - Collaboratiion Diagram dell'operazione di esecuzione di una query sul Catalogo.132 Figura 67 - Sequence Diagram ad alto livello dell'operazone di scaricamento di un LO Figura 68 - Collaboration Diagram dell'operazione di scaricamento di un LO Figura 69 - Reports dell'esecuzione del test funzionale del sottosistema Catalogue Figura 70 - Test di performance dell operazione di restituzione dei parametri per il download di un LO del Web service Catalogue Figura 71 - Test di performance dell operazione di esecuzione di una query sul Catalogo del Web service Catalogue Figura 72 - Test di performance dell operazione di conferma di avvenuto download del Web service Catalogue Figura 73 - Dettagli delle operazioni testate sul Web service Catalogue (numero di volte eseguite, media del tempo in ms, minimo tempo, max tempo, percentuale di errore, numero ipotizzato di operazioni per secondo). (in locale) Figura 74 - Rappresentazione grafica della media, mediana, deviazione standard dei tempi impiegati nell eseguire le operazioni(300) e il numero di richieste per minuto relative al Web service Catalogue. (in locale) Figura 75 - Rappresentazione grafica dei tempi impiegati nell eseguire le singole operazioni esposte dal Web service Catalogue. (in locale) Figura 76 - Deployment e organizzazione delle distribuzioni rilasciate dall'infrastruttura di Comunicazione Figura 77 - Reports di esecuzione dei tests funzionali del Repository Virtuale su rete Figura 78 - Dettagli delle operazioni testate del WS (numero di volte eseguite, media del tempo in ms, minimo tempo in ms, max tempo in ms, percentuale di errore, numero ipotizzato di operazioni per secondo). (sulla rete) Figura 79 - Rappresentazione grafica della media(ms), mediana (ms), deviazione standard(ms) e il numero di richieste per minuto dei tempi impiegati nell eseguire le operazioni(300). (sulla rete) Figura 80 - Rappresentazione grafica dei tempi impiegati nell eseguire le singole operazioni (sulla rete) Figura 81 - Testing funzionale dell'operazione di richiesta della lista di LO

12 Figura 82 - Dettagli delle operazioni testate del WS (numero di volte eseguite, media del tempo in ms, minimo tempo in ms, max tempo in ms, percentuale di errore, numero ipotizzato di operazioni per secondo). (sulla rete) Figura 83 - Rappresentazione grafica della media(ms), mediana (ms), deviazione standard(ms) e il numero di richieste per minuto dei tempi impiegati nell eseguire le operazioni(60). (sulla rete) Figura 84 - Rappresentazione grafica dei tempi impiegati nell eseguire le singole operazioni (sulla rete) Figura 85 - Risultati dei tests funzionali eseguiti dall'interfaccia Figura 86 - Dettagli delle operazioni testate del WS (numero di volte eseguite, media del tempo in ms, minimo tempo in ms, max tempo in ms, percentuale di errore, numero ipotizzato di operazioni per secondo). (sulla rete) Figura 87 - Rappresentazione grafica della media(ms), mediana (ms), deviazione standard(ms) e il numero di richieste per minuto dei tempi impiegati nell eseguire le operazioni(300). (sulla rete) Figura 88 - Rappresentazione grafica dei tempi impiegati nell eseguire le singole operazioni. (sulla rete)

13 Indice delle Tabelle Tabella 1 - Gli obbiettivi e le milestones di ogni iterazione...90

14 Contesto formativo La tesi è stata affiancata da un periodo di tirocinio svolto presso il NetLab 1, il Laboratorio di Ricerca e Sperimentazione su Reti e Multimedialità dell Istituto di Analisi dei Sistemi ed Informatica 2 Antonio Ruberti del Consiglio Nazionale delle Ricerche (IASI-CNR). L Infrastruttura di Comunicazione, oggetto di studio, è lo sviluppo di parte di un sistema finalizzato all interscambio ed alla condivisione di materiale didattico da parte dei dottorati di ricerca avviato nell ambito del progetto FIRB Web Minds 3. Va sottolineata, in modo particolare, la collaborazione con il Gruppo architettura layer di interazione 4 che ha definito l architettura generale [1] del sistema e l Infrastruttura di Comunicazione [2]. Introduzione L obbiettivo della tesi è la definizione di un Infrastruttura di Comunicazione per un sistema di catalogazione semantica e condivisione distribuita di Learning Objects, avente come scopo la condivisione e l interscambio di materiale didattico tra Dottorati di ricerca, a carattere informatico, tenuti in diversi Atenei italiani. Il sistema, caratterizzato da un significativo livello di distribuzione, prevede la seguente organizzazione in termini di componenti: uno o più Repositories, un Catalogo e una o più Interfacce. Un Repository è semplicemente un contenitore di LO, con funzioni di creazione, modifica e rimozione che ha l obbligo di registrarsi presso il registro centralizzato del sistema; il Catalogo è responsabile della gestione della banca dati centralizzata, costituita dai metadata (Learning Object Metadata) associati a tutti i LO registrati e del motore inferenziale utilizzato per eseguire le ricerche semantiche; l Interfaccia si occupa di gestire l'interazione con gli utenti interessati alla ricerca e allo scaricamento dei LO. Al fine di rendere Di cui fanno parte il Prof. Giorgio Gambosi e il Dott. Marco Bianchi

15 trasparente la natura distribuita del sistema e garantire l interconnessione tra le vari componenti appare necessaria e utile la progettazione di un Infrastruttura di Comunicazione, oggetto dello studio che seguirà. La progettazione di una simile Infrastruttura è conseguenza di un opportuna analisi di ricerca e di scelta dei differenti approcci tecnologici e metodologici. L Infrastruttura di Comunicazione si modellerà su un architettura di tipo Peer to Peer che prevede la presenza di un registro centralizzato dei Repositories. I Repositories rappresentano i peers che dispongono delle risorse (Learning Objects) necessarie agli altri peers (le interfacce). Le scelte architetturali dell Infrastruttura di Comunicazione sono legate alla libertà tecnologica che viene fornita ai singoli componenti distribuiti del sistema, in modo da non porre nessun vincolo sulle scelte implementative da adottare. L eterogeneità dei componenti che ne consegue, relativamente a Interfacce e Repositories, suggerisce di non fare nessuna ipotesi in merito alla relativa implementazione ma porta a considerare soluzioni di tipo aperto che incrementano l espandibilità. L espandibilità contribuisce ad aumentare le abilità delle componenti e del sistema nel cooperare con gli altri. L impronta di eterogeneità e l alto grado di distribuzione, uniti al requisito di espandibilità che l Infrastruttura di Comunicazione deve considerare, inducono ad adottare tecnologie aperte come i Web services. I concetti che sono alla base dei Web services costituiscono ottime soluzioni ai problemi ricorrenti nell ambito di integrazione e interazione di componenti e sistemi eterogeneamente distribuiti. L infrastruttura di Comunicazione, difatti, facendo uso dei Web services interagirà con tecnologie consolidate come standard de-facto. Tra queste, la più affermata, SOAP (Simple Objects Access Protocol), definito come il fulcro dell interoperabilità, è il protocollo di scambio basato su messaggi XML che sta alla base della comunicazione nei Web services. L Infrastruttura di Comunicazione implementerà un insieme di componenti software (i Web services) che possono essere richiamate utilizzando XML (SOAP) ed il protocollo internet HTTP. I Web services, SOAP, XML e HTTP consentono potenzialmente una interconnessione delle 14

16 componenti distribuite, considerando una eventuale eterogeneità tra i componenti del sistema. La loro potenzialità consiste, inoltre, nella loro indipendenza tanto dalla piattaforma quanto dai linguaggi di programmazione utilizzati per svilupparli. I Web services, pertanto, si propongono come la soluzione più idonea alla realizzazione dell Infrastruttura di Comunicazione. Sebbene, alla luce di quanto detto, non appare rilevante l utilizzo di uno specifico linguaggio di programmazione, per il lavoro svolto, la scelta è stata orientata verso il linguaggio Java. Il suo uso, in ambiente SOAP, oltre a rendere scalabile e portabile le applicazioni che si vogliono costruire, favorisce interoperabilità con applicazioni eterogenee residenti su piattaforme diverse risolvendo problemi di incompatibilità. Nel caso di Interfacce e Repositories realizzati utilizzando tecnologie diverse e quindi un linguaggio di programmazione diverso da Java, sarà possibile implementarne la corretta interazione con il resto del sistema operando direttamente a livello di invocazione ed implementazione dei Web services. A tal fine, i Web services implementati dall Infrastruttura di Comunicazione comprenderanno la descrizione delle interfacce dei Web services sotto forma di documenti WSDL (Web Service Description Language). L utilizzo di Java come linguaggio di programmazione per sviluppare applicazioni SOAP, richiede, inoltre, l implementazione Java per SOAP del binding specifico. Tra gli ambienti open source ha avuto un notevole successo l implementazione di SOAP per Java fornita dall'apache Group denominata Axis (Apache extensible Interaction System). La caratteristica interessante di Axis è che permette di integrare facilmente i Web services e in particolare la messaggistica SOAP nell Infrastruttura di Comunicazione senza la necessità di implementare SOAP o altri protocolli Internet a basso livello. Quanto detto permette di scegliere Axis come ambiente SOAP per l implementazione dei Web services dell Infrastruttura di Comunicazione. Per quanto concerne la metodologia applicata all organizzazione delle attività di progettazione e sviluppo, e delle fasi inerenti la realizzazione 15

17 dell Infrastruttura di Comunicazione, si è optato nell adottare un approccio misto tra metodologia UP (Unified Process) e metodologia XP (extreme Programming). L UP, con la separazione in iterazioni, si presta meglio ad una realizzazione incrementale dell Infrastruttura di Comunicazione distribuendo il lavoro in sottoproblemi. Un processo guidato da incrementi aggiuntivi e perfezionativi supporta una divisione in sottosistemi dell Infrastruttura consentendo di implementare, testare e rilasciare versioni ridotte della stessa (che implementino un sottoinsieme delle funzionalità). Utilizzando un approccio UP (nello specifico UP for EDUcational), nella fase di analisi e descrizione dei requisiti, di progettazione e di pianificazione, si catturano le informazioni chiave per la realizzazione del progetto. Le informazioni vengono schematizzate e organizzate negli artefatti che documentano le attività e le scelte, facilitando il mantenimento. Tuttavia, UP tralascia in qualche modo gli aspetti concreti e pragmatici della fase di implementazione e di testing, senza fornire gli strumenti concreti che la caratterizzano. L implementazione ed il testing sono però approfonditi nella metodologia XP. Progettare e implementare i tests, prima di codificare (implementare) una particolare funzionalità, è un aspetto molto interessante per un Infrastruttura di Comunicazione che si fa garante di una serie di chiamate a servizi remoti. L utilizzo di tools e frameworks open source, sono alla base della filosofia XP nonché le fondamenta stesse su cui si basa l implementazione e il testing dell Infrastruttura. L approccio misto che unisce le funzionalità analitiche dell UPEDU all agilità della metodologia XP, permette di ottenere un processo di produzione del software che garantisce un prodotto di qualità ed al tempo stesso scalabile, affidabile, mantenibile, efficiente e facile da usare. Struttura della tesi La tesi consta principalmente di due parti: nella prima parte, vengono trattati gli aspetti che non sono stati oggetto di studio del corso di Laurea in 16

18 Informatica (Scenario Tecnologico e Metodologico); nella seconda parte della tesi, invece, viene analizzato il caso di studio oggetto del tirocinio e della tesi: l Infrastruttura di Comunicazione. La prima parte della tesi, comprendente i primi tre capitoli, analizza: I Web services e le tecnologie correlate, come SOAP, WSDL, UDDI, mettendone in risalto i vantaggi e approfondendo gli aspetti che interessano l Infrastruttura di Comunicazione (Capitolo 1). L implementazione di SOAP per Java adottata per l implementazione dei Web services dell Infrastruttura di Comunicazione: Axis. Viene dettagliata l architettura, il modo in cui lavora il framework e le funzionalità che fornisce. (Capitolo 2) Le metodologie che definiscono il processo di produzione del software e che sono state adottate per definire il ciclo di vita dell Infrastruttura di Comunicazione. (Capitolo 3). La seconda parte della tesi, invece, analizza gli aspetti legati all Infrastruttura di Comunicazione: Partendo dal contesto, in cui è calata l Infrastruttura di Comunicazione, vengono motivate le scelte tecnologiche e metodologiche che sono state prese in considerazione per la realizzazione della stessa. (Capitolo 4) Vengono definiti e analizzati i requisiti che quantificano il lavoro e consentono la pianificazione dello stesso e la divisione dell Infrastruttura in sottosistemi. Viene definito lo scheletro dell architettura dell Infrastruttura di Comunicazione in base alle scelte progettuali e tecnologiche mettendone in rilievo i pattern utilizzati. (Capitolo 5). Partendo dallo scheletro dell architettura definita vengono definiti i sottosistemi (VirtualRepository, Repository, Catalogue) dell Infrastruttura: dopo aver selezionato i casi d uso, si fornisce il modello di analisi, il disegno architetturale (in termini di moduli e classi che compongono il sottosistema), la pianificazione dei tests e i 17

19 risultati prodotti dall esecuzione degli stessi. (Capitolo 6, Capitolo 7, Capitolo 8). L integrazione, il deployment e il testing dell Infrastruttura di Comunicazione vengono approfonditi. Gli aspetti relativi all organizzazione dei rilasci e delle distribuzioni sono delineati in modo da poter consentire ai clienti dell Infrastruttura l interazione con essa. Tests funzionali, di performance e di scalabilità sono eseguiti sull Infrastruttura: i loro risultati vengono documentati e commentati (Capitolo 9). Alla tesi sono, inoltre, allegati i documenti prodotti durante il processo di produzione del software. Questi documenti sono utili ai fini del mantenimento dell Infrastruttura di Comunicazione. I modelli dei documenti sono quelli forniti da UPEdu. 18

20 I Scenario tecnologico e metodologico

21 1. Web services Oggigiorno, l uso principale del World Wide Web è l accesso interattivo a documenti e applicazioni. Nella maggior parte dei casi, tale accesso è effettuato da utenti, tramite Web browser, audio players o altri sistemi di front end interattivi. Il Web può espandere ampiamente il proprio raggio di azione e la propria influenza solo se la sua azione venisse estesa a supporto della comunicazione tra diverse applicazioni nonché tra differenti programmi. - Dal W3C XML Protocol Working Group Charter [3] Una delle aree nello sviluppo di applicazioni e servizi informatici che presentano maggiore sviluppo è probabilmente quella che ruota attorno al concetto di comunicazione B2B (Business to Business). Le casse continue cooperano con le banche, i registratori di cassa comunicano con le aziende che offrono servizi di credito, i sistemi di gestione delle scorte procurano nuovi prodotti da vari fornitori. B2B, quindi, vuol dire anche flusso di informazioni di tipo A2A (Application to Application). I Web services [4] introducono un nuovo modo per lo scambio di informazioni tra aziende e una nuova concezione dello sviluppo del software. Le aziende possono pensare al software modularmene. Nelle organizzazioni con applicazioni eterogenee e architetture distribuite, l introduzione di Web services standardizza il meccanismo di comunicazione e permette interoperabilità tra le applicazioni, basate su differenti linguaggi di programmazione, localizzate su diverse piattaforme. 1.1 Cosa sono i Web services Dare una definizione di Web service è allo stesso tempo semplice e complesso; questo potrebbe essere dovuto alla dinamicità dei Web services stessi. 20

22 Un servizio Web è un sistema software identificato da una URI le cui interfacce pubbliche e i binding sono descritti da XML. La sua definizione può essere rintracciata da altri sistemi software. Questi sistemi software possono interagire secondo quanto scritto nella definizione, usando messaggi XML veicolati da protocolli internet. [5] In sostanza, un Web service è un interfaccia di rete accessibile alle funzionalità di un applicazione, costruito usando tecnologie standard di Internet. Questo è illustrato in Figura 1. Figura 1 - Un Web service permette l'accesso ad applicazioni usando tecnologie standard 1.2 Caratteristiche dei Web services Il successo dei Web services dipende dai seguenti fattori: Sono basati su XML: il ricorso a tale formalismo, per la rappresentazione dei dati per tutti i protocolli e le tecnologie dei Web services, permette di raggiungere la più completa indipendenza dal linguaggio di programmazione e dalla piattaforma utilizzata. Hanno basso accoppiamento (coupling): l utente non è legato in modo diretto ad un determinato Web service. L'interfaccia del servizio potrebbe cambiare leggermente senza che la capacità dell'utente di interagire con esso ne sia compromessa. Sono a grana fine: tecnologie object-oriented come java espongono questi servizi attraverso metodi individuali. I Web services permettono di definire un modo naturale per avere servizi a grana fine che accedono alla business logic. 21

23 Possono essere sincroni o asincroni: nei contesti sincroni quando un cliente invoca un servizio si sospende, nell attesa della risposta da parte del servizio invocato. Nei contesti asincroni una volta effettuata la chiamata il cliente può proseguire la sua esecuzione senza attendere il completamento del servizio remoto. I contesti asincroni sono particolarmente adeguati quando l'elaborazione da parte del Web service è particolarmente onerosa e richiede tempo. Supportano chiamate stile RPC: i Web services permettono ad un cliente di invocare metodi su oggetti remoti facendo uso di un protocollo basato su XML (SOAP) Supportano lo scambio di documenti: con i Web services si possono rappresentare e scambiare in maniera uniforme anche documenti. I Web services, inoltre, lavorano ad un livello di astrazione tale da rendere possibile connettere ogni sistema operativo, piattaforma hardware, o linguaggio di programmazione. Figura 2 - Un semplice Web service Ci sono diverse alternative [6] per lo scambio di messaggi XML. Per esempio, si potrebbe usare XML Remote Procedure Calls (XML-RPC) o SOAP. Alternativamente, si potrebbe semplicemente usare HTTP GET/POST e passare documenti XML arbitrari (vedi Figura 3). 22

24 Figura 3 - Messaggistica XML per i Web services Ad aumentare le potenzialità dei Web services sono altre due proprietà di fondamentale importanza: Un Web service è self-describing. Se si pubblica un Web service, si dovrebbe pubblicare anche la sua interfaccia pubblica. L interfaccia pubblica, scritta in XML, viene utilizzata per identificare tutti i metodi pubblici, gli argomenti dei metodi e i valori di ritorno. Un Web service è discoverable. Se si crea un Web service, esiste un meccanismo relativamente semplice che permette la sua pubblicazione. Similmente, esiste un meccanismo semplice che permette, alle parti interessate, di cercare un servizio e localizzare la sua interfaccia pubblica. 1.3 Perché usare i Web services Tradizionalmente, le Web applications permettono un interazione tra un utente finale e un sito web. I Web services, invece, sono orientati ai servizi e permettono una comunicazione A2A (Application to Application) su Internet e una semplice accessibilità ad applicazioni e dispositivi eterogenei. Elenchiamo qui di seguito le maggiori ragioni tecniche [7] affinché si adottino i Web services in una Web application: 23

25 I Web services possono essere invocati attraverso meccanismi RPC basati su XML che possono attraversare i firewalls. Fornendo una soluzione basata su messaggi XML, i Web services sono cross-platform e cross-language. I Web services facilitano in modo notevole l integrazione di applicazioni, utilizzando un infrastruttura leggera che non influisce sulla scalabilità. I Web services permettono interoperabilità tra applicazioni eterogenee. 1.4 L architettura dei Web services Ci sono due modi per considerare l architettura di un Web service. Il primo è esaminare i ruoli individuali di ogni attore del Web service; il secondo è esaminare la pila dei protocolli di un Web service I ruoli in un Web service Ci sono tre ruoli principali all interno dell architettura di un Web service come è possibile evincere dalla Figura 4. Figura 4 - Modello operazionale dei Web services, visualizza ruoli e relazioni. Service provider: è il fornitore del servizio. Il service provider implementa il servizio e lo rende disponibile su Internet. Da una prospettiva business, questo 24

26 rappresenta il proprietario del servizio. Dal punto di vista architetturale, è la piattaforma che ospita l accesso al servizio. [50] Service requestor: è responsabile dell invocazione del servizio. Il service requestor localizza il Web service usando il service broker, invoca il servizio richiesto che viene eseguito dal service provider. Da una prospettiva business, è il cliente richiedente la soddisfazione di determinate funzioni. Da una prospettiva architetturale, questa è l applicazione che effettua la ricerca e invoca o inizializza un interazione con il servizio. [50] Service registry: è l elenco logicamente centralizzato dei servizi. Il registry fornisce un punto centrale dove gli sviluppatori possono pubblicare nuovi servizi e trovarne uno già esistente. Il registry, dunque, si comporta da intermediario (broker) per le società ed i loro servizi Stack dei protocolli di un Web service Un altro modo per considerare l architettura di un Web service è esaminare la pila di protocolli utilizzati dallo stesso. La pila, ancora in fase di evoluzione, possiede 5 strati principali ( Figura 5 - Pila concettuale dei Web services). Figura 5 - Pila concettuale dei Web services [7] 25

27 Network: i Web services devono essere accessibili tramite rete per essere invocati da un service requestor. I Web services che sono disponibili comunemente su Internet utilizzano a questo strato HTTP (standard de facto). Altri protocolli comunque sono supportati, inclusi SMTP e FTP. XML-Based Messaging: rappresenta l uso di XML come protocollo per lo scambio dei messaggi. Il protocollo scelto per lo scambio di messaggi XML è SOAP. SOAP è lo standard document-centric, utilizzato per avvolgere i messaggi e le chiamate di procedura remota usando XML. Il messaggio SOAP viene spedito come richiesta HTTP di tipo POST. Service Description: rappresenta lo strato responsabile della descrizione dell interfaccia pubblica di un Web service. Il Web Service Description Language (WSDL) è lo standard de facto, basato su XML, per la descrizione di un servizio. WSDL, oltre a garantire l interoperabilità, definisce l interfaccia e il modo in cui si interagisce con il servizio. Service Publication e Service Discovery: rappresenta lo strato responsabile della centralizzazione dei servizi fornendo le funzionalità di pubblicazione e ricerca di un servizio. Attualmente, lo standard utilizzato, basato su XML è Universal Description, Discovery e Integration (UDDI). Service Flow: descrive come comunicazioni service-to-service, collaborazioni e flussi sono eseguiti. Web service Flow Language (WSFL) è usato per descrivere queste interazioni. 1.5 Tecnologie dei Web services In questo paragrafo si analizzeranno nel dettaglio le tecnologie essenziali utilizzate dalle principali piattaforme di Web services. Le tecnologie che verranno descritte sono gli standard affermati e le fondamenta stessi dei Web services. 26

28 1.5.1 SOAP: il fulcro dell interoperabilità SOAP [8] (Simple Object Access Protocol) è un metodo di trasporto basato su XML e progettato per lo scambio di informazioni in ambiente distribuito. SOAP utilizza protocolli di trasporto di livello inferiore, come HTTP. I messaggi SOAP, in realtà possono essere trasmessi con tecniche differenti, tra cui il protocollo SMTP. Bisogna sottolineare il fatto che SOAP definisce un protocollo privo di stato (stateless): quindi non è necessario mantenere una sessione, dato che gli elementi di stato sono contenuti nel messaggio stesso Cosa definisce SOAP SOAP definisce il modo in cui il messaggio XML è strutturato, le convenzioni che rappresentano una RPC (Remote Procedure Call) nel messaggio XML, il binding al protocollo HTTP per assicurare che il messaggio XML venga trasportato in modo corretto e infine definisce le convenzioni per restituire un errore al mittente del messaggio. SOAP non definisce semantiche per i dati e le chiamate, ma fornisce agli sviluppatori i mezzi per farlo (attraverso i Namespaces XML ). Quello che definisce, invece, sono le regole fondamentali per processare un messaggio, rimanendo completamente indipendente dal protocollo di trasporto utilizzato La struttura di un messaggio SOAP La struttura dei messaggi definisce gli elementi XML di base che occorrono per costruire le richieste SOAP. 27

29 Figura 6 - Struttura del messaggio SOAP Un messaggio SOAP [9] è un documento XML ben formato che contiene un elemento Envelope, un elemento opzionale Header e un elemento body obbligatorio, come visualizzato in figura 6. L elemento envelope serve come contenitore per il body e l header e anche come indicatore ad evidenziare che si tratta di un messaggio SOAP. Il tag </Envelope> indica che l elaborazione può iniziare (o eventuali allegati) poiché tutte le informazioni sono state raccolte. L envelope, essenzialmente, è solo una struttura di impacchettamento. L elemento header è opzionale, ma se presente, dovrebbe essere il primo elemento da considerare. Questo contiene informazioni aggiuntive, per esempio relative all autenticazione, all instradamento o all identificativo di transazione. SOAP non definisce nessuna entry nel blocco header, quindi è possibile aggiungere altre funzionalità. L header potrebbe contenere meta-data che aiutano a descrivere il contenuto principale di un messaggio SOAP, 28

30 informazioni su come indirizzare il messaggio a indirizzi differenti, sicurezza e cosi via. Il body, obbligatorio, contiene le informazioni principali per il destinatario del messaggio. Le informazioni possono essere elementi XML che descrivono l invocazione di una procedura per esempio, descrivendo argomenti e parametri insieme al nome della procedura oppure altro contenuto XML, come un ordine di acquisto. Queste due tecniche sono genericamente chiamate messaggistica SOAP RPC-style e document-style, rispettivamente. Il body può, infine, contenere un blocco speciale fault che indica errori a livello di protocollo. Le regole che definiscono come un particolare messaggio SOAP è spedito su un particolare protocollo di trasporto prendono il nome di SOAP binding al particolare protocollo SOAP con allegati E possibile aggiungere ad un messaggio SOAP un allegato [10]. Questo è reso possibile grazie ad un binding speciale che si serve della codifica MIME multipart/related anziché di text/xml. La codifica multipart/related frammenta il contenuto della richiesta HTTP in parti differenti: per convenzione, la prima parte contiene l envelope SOAP ed è di tipo text/xml. Questa soluzione è interessante poiché lascia del tutto intatto il documento SOAP: in effetti, quest ultimo è del tutto ignaro del binding a parti multiple Descrivere i Web services: WSDL Il Web Service Description Language (WSDL) [11], basato su XML, fornisce il meccanismo attraverso il quale le definizioni dei Web services sono rese pubbliche. WSDL non si limita alla semplice descrizione delle procedure d impiego di un servizio, ma va oltre definendo anche il protocollo di trasporto. WSDL consente ai Service Providers di fornire il modo in cui le richieste, da inoltrare ai Web services, dovranno essere definite. In un documento WSDL si specificano la locazione fisica e le operazioni disponibili 29

31 per il servizio descritto. Si ha una descrizione astratta che comprende i tipi, i messaggi e le operazioni; si ha inoltre una descrizione concreta che dipende dal binding e dalla posizione in cui si trova il servizio (figura 7). Figura 7 - Rappresentazione concettuale del documento WSDL I principali tags XML che compongono una descrizione WSDL sono: <types>: all'interno di questo elemento vengono definiti i tipi di dato complessi utilizzati dal Web service, servendosi della stessa sintassi degli schemi XML. <message>: serve ad indicare quali sono le parti di cui è composto un messaggio. Le parti hanno lo stesso ruolo dei parametri delle funzioni. <porttype>: raggruppa le operations disponibili per il Web service, elencando per ognuna quali messages ne fanno parte. Il porttype può 30

32 essere visto come una libreria di funzioni (nei linguaggi imperativi) o come una classe (nei linguaggi ad oggetti). <binding>: raggruppa un insieme di operations e gli assegna un tipo di binding (che indica un porttype). <operation>: specifica quali sono i messages di input e di output per la funzione che rappresenta. <service>: raccoglie tutte le ports del Web service <port>: rappresenta una singola implementazione del Web service: contiene un binding e un indirizzo di rete (al quale le richieste verranno inviate) Ricerca e pubblicazione dei Web services Una volta creata la descrizione di un Web service, rimane il problema di come far giungere agli utenti questa descrizione. Tipicamente, si agisce in tre direzioni: Direct publication: il Service Provider invia direttamente al client il documento WSDL che descrive il Web service. Static discovery: il Client possiede la descrizione WSDL ottenuta per direct publication, e la rende disponibile ad un'applicazione a tempo di esecuzione. Dynamic discovery: Il Client può venire a conoscenza del Web service anche a tempo di esecuzione, tramite un registro UDDI. UDDI (Universal Description Discovery and Integration) [12] è un directory service, dove le aziende possono registrare i propri Web services e cercarne altri. Un registro UDDI contiene informazioni riguardanti un insieme di Web services, tra le quali anche la loro descrizione WSDL, e i dati in esso contenuti sono accessibili tramite SOAP. UDDI è stato proposto per fornire uno standard che mettesse in comunicazione le aziende con i clienti e i partners fornendo informazioni riguardanti i propri prodotti e servizi. 31

33 Esso è pensato per fornire tre tipi di servizi: le pagine bianche, comprendono le informazioni di base sui contatti dell'azienda (ragione sociale, indirizzo, codice DUNS (Data Universal Numbering System)); le pagine gialle, comprendono le informazioni sui servizi Web in base alle loro categorie, per consentire, a chi esegue ricerche, di localizzare un certo tipo di servizio (ad esempio produttori di automobili); le pagine verdi, infine, comprendono informazioni tecniche sulle funzioni supportate dal servizio Web ospitato dall'azienda (riferimento alle descrizioni dei Web services, localizzazione). 32

34 2. Sviluppo di Web services usando Java Come si è potuto constatare (vedi capitolo 1), invocare un Web service significa inviargli un messaggio SOAP contenente una richiesta di esecuzione di un'operazione e i dati di input necessari. Quello che il Web service ritornerà sarà un altro messaggio SOAP, contenente il risultato dell'operazione richiesta. SOAP non definisce un binding ad uno specifico linguaggio di programmazione: è compito del progettista scegliere un linguaggio e definirne l implementazione. In questo contesto [13], usare Java come linguaggio di programmazione per sviluppare applicazioni SOAP richiede l implementazione Java [14] per SOAP del binding specifico. Allo stato attuale, ci sono molti venditori di applicazioni SOAP che hanno dato vita ad implementazioni di SOAP basate su Java per sviluppare da applicazioni Web a Web services. In generale, l uso di Java per lo sviluppo di applicazioni SOAP rende scalabile e portabile le applicazioni che si vogliono costruire e possono, inoltre, interoperare con applicazioni eterogenee residenti su piattaforme diverse risolvendo problemi di incompatibilità. Inoltre, avere applicazioni basate su SOAP che adottano un infrastruttura basata su J2EE [15], permette di ereditare le caratteristiche dei containers come transazioni, sicurezza, connettività a back-end. Una lunga lista di comunità open source e fornitori di piattaforme basate su Web services hanno realizzato implementazioni SOAP adottando la piattaforma Java e le API che mette a disposizione. Tra queste ha avuto un notevole successo l implementazione di SOAP per Java fornita dall'apache Group denominata Axis (Apache extensible Interaction System). 2.1 Apache Axis Axis [16], un toolkit per il deploying e l uso di Web services, permette agli sviluppatori di integrare servizi Web all interno delle loro applicazioni senza la necessità di imparare SOAP o altri protocolli Internet a basso livello. Axis non è un semplice engine SOAP, ma un framework per realizzare sistemi di 33

35 integrazione (clients, servers, gateways, etc.) basati su SOAP [17]. Il progetto non è una revisione della precedente versione del toolkit, Apache SOAP 2.2, ma una completa riscrittura che nasce dalla necessità di migliorare le prestazioni e supportare un varietà più ampia di protocolli. Axis include [18]: Un semplice stand-alone server, Un server che si inserisce all interno di un servlet engines come Tomcat, Supporto esteso per il Web service Description Language (WSDL) Un tool per la generazione di classi Java a partire da un documento WSDL e viceversa, Un tool per i monitorare pacchetti TCP/IP Caratteristiche principali di Axis Uno dei tools più interessanti che mette a disposizione Axis [19] è WSDL2Java. WSDL2Java può generare sia il codice degli stubs per il client che per il server; inoltre genera anche i beans per modellare i dati del modello definito dagli XML-Schema. WSDL2Java popolerà poi automaticamente questi beans a partire dalle informazioni in formato XML. Questo processo in generale è chiamato data binding. Per la validazione dei documenti XML occorre un parser XML. Per interagire con un parser, Axis [20] si serve delle API JAXP [21]. Quindi si dà la possibilità di sceglierne uno qualsiasi tra quelli compatibili 5 con JAXP. Un altro strumento che mette a disposizione Axis è Java2WSDL: a partire da una classe java che rappresenta il Web service genera il documento WSDL di descrizione del servizio. 5 Nello sviluppo del lavoro, per coerenza con il progetto Apache XML, verrà scelto il parser Xerces2 [49]. 34

36 2.1.2 Funzionalità e vantaggi di Axis Vengono di seguito elencate le funzionalità e i vantaggi [18] nell utilizzo di Axis: Velocità: il meccanismo di parsing utilizzato nell implementazione di Apache SOAP era basato su DOM (Document Object Model), il quale impiega più tempo rispetto ad un parser basato su SAX (Simple API for XML). Infatti, Axis usa SAX, un parser basato sugli eventi che opera più a basso livello e permette di ottenere alte prestazioni. Flessibilità: Axis fornisce funzionalità per facilitare l inserimento di nuove estensioni nell engine che consentono di personalizzare l elaborazione dell header e la gestione del sistema. Axis fornisce un deployment descriptor per descrivere le vari componenti come i servizi, gli oggetti handler, i serializzatori e i deserializzatori e così via. Il deployment descriptor (WSDD) è usato per eseguire il deployment di un Web service. Deployment orientato alle componenti: Axis presenta il concetto di handlers per implementare patterns comuni di elaborazione per le applicazioni. Un handler, un oggetto capace di processare un messaggio, è il responsabile delle elaborazioni specifiche associate al flusso di input, output e fault. Stabilità: Axis definisce una serie di interfacce stabili, che facilitano la migrazione verso nuove versioni Axis. Framework di trasporto: Axis, come anticipato, offre un framework di trasporto fornendo senders e listeners per SOAP sopra vari protocolli come SMTP, FTP, etc L architettura di Axis Axis gioca un ruolo fondamentale sia sul lato client del Web service (colui che utilizza il servizio) che sul lato server (colui che fornisce il servizio). Verranno analizzati entrambi gli aspetti architetturali [22] mettendo in rilievo le componenti che formano il nucleo di Axis e della comunicazione. Molto semplicemente, Axis è tutto ciò che riguarda l elaborazione dei messaggi. 35

37 Durante l elaborazione dei messaggi vengono eseguiti una serie di Handlers invocate in un ordine che varia a secondo della configurazione del deployment e della posizione dell Engine (client o server). L elaborazione di un servizio SOAP è fatta passando un context message ad ogni componente. Un context message è una struttura che contiene un request message, un response message e una lista di proprietà (attributi dell header SOAP). Prima di analizzare il funzionamento dell architettura definiamo quelli che sono i concetti chiave di Axis: Le Handler [23] sono utili ai fini del processamento dei messaggi; un handler potrebbe spedire una richiesta e ricevere una risposta oppure processare una richiesta e produrre una risposta. Un Handler può appartenere a tre famiglie: transport-specific, service-specific o global. Le Handlers di ciascuna famiglia sono combinate in Chains. Quindi la sequenza complessiva di Handlers comprende tre tipi di Chains: transport, global e service. Si è detto che Axis interviene in due modi: quando viene invocato come server e quando viene invocato come client. Il cammino del Message sul server: come visualizzato in Figura 8 elenchiamo i passi principali. 36

38 Figura 8 - Il cammino del Message sul Server. I cilindri piccoli rappresentano le handlers, quelli grandi, invece, rappresentano le chains. Un request message è spedito al nodo di elaborazione del messaggio del transport listener. Il transport listener converte il messaggio in entrata in un oggetto Message e lo incapsula in un oggetto MessageContext. Successivamente il transport listener carica varie proprietà specificate come attributi di SOAP (Es: l action header di SOAP) e imposta il tipo di trasporto come proprietà sul MessageContext. Il tipo di trasporto, come evidenziato, può essere HTTP, SMTP o FTP. Una volta che il MessagceContext è inizzializzato viene passato all AxisEngine. Dopo che l AxisEngine ha individuato il tipo di trasporto, viene invocata la request Chain del Transport (vedi figura 8), se questa esiste, passandogli il MessageContext. L Engine, a questo punto, localizza una global request Chain e invoca gli Handlers specificati; dopodichè alcuni Handlers impostano il campo servicehandler del MessageContext Il campo servicehandler indicherà l handler da invocare per eseguire il servizio richiesto (Es: RPC). I Services oltre a contenere una request Chain e una response Chain, contengono anche un Provider, un Handler responsabile dell implementazione della logica del back end del servizio. Nel caso di richieste RPC il Provider invoca l oggetto della classe specificata nel file di deploy. 37

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

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

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 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

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

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

Reti di Telecomunicazione Lezione 6

Reti di Telecomunicazione Lezione 6 Reti di Telecomunicazione Lezione 6 Marco Benini Corso di Laurea in Informatica marco.benini@uninsubria.it Lo strato di applicazione protocolli Programma della lezione Applicazioni di rete client - server

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

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Le Reti di Calcolatori (parte 2) Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela

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

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

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

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

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Le Reti di Calcolatori (parte 2) Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela

Dettagli

Parte II: Reti di calcolatori Lezione 9

Parte II: Reti di calcolatori Lezione 9 Università di Roma Tor Vergata Corso di Laurea triennale in Informatica Sistemi operativi e reti A.A. 2013-14 Pietro Frasca Parte II: Reti di calcolatori Lezione 9 Martedì 1-04-2014 1 Applicazioni P2P

Dettagli

Processi BPEL. Obiettivi

Processi BPEL. Obiettivi Università degli studi di Roma Tor Vergata Facoltà di Ingegneria Processi BPEL Corso di Sistemi Distribuiti Stefano Iannucci Anno accademico 2009/10 Email: sd@chmod.it Obiettivi Esercitazione pratica su:

Dettagli

Introduzione alle applicazioni di rete

Introduzione alle applicazioni di rete Introduzione alle applicazioni di rete Definizioni base Modelli client-server e peer-to-peer Socket API Scelta del tipo di servizio Indirizzamento dei processi Identificazione di un servizio Concorrenza

Dettagli

SWIM v2 Design Document

SWIM v2 Design Document PROGETTO DI INGEGNERIA DEL SOFTWARE 2 SWIM v2 DD Design Document Matteo Danelli Daniel Cantoni 22 Dicembre 2012 1 Indice Progettazione concettuale Modello ER Entità e relazioni nel dettaglio User Feedback

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

Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni.

Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni. <Task AP3> Progetto interregionale ICAR Interoperabilità e Cooperazione Applicativa tra le Regioni AP3-Documento Descrittivo degli Accordi di Servizio Versione AP3-specificaADSv1.2.1.doc Pag. 1

Dettagli

BPEL: Business Process Execution Language

BPEL: Business Process Execution Language Ingegneria dei processi aziendali BPEL: Business Process Execution Language Ghilardi Dario 753708 Manenti Andrea 755454 Docente: Prof. Ernesto Damiani BPEL - definizione Business Process Execution Language

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

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

Componenti Web: client-side e server-side

Componenti Web: client-side e server-side Componenti Web: client-side e server-side side Attività di applicazioni web Applicazioni web: un insieme di componenti che interagiscono attraverso una rete (geografica) Sono applicazioni distribuite logicamente

Dettagli

Informatica per la comunicazione" - lezione 9 -

Informatica per la comunicazione - lezione 9 - Informatica per la comunicazione" - lezione 9 - Protocolli di livello intermedio:" TCP/IP" IP: Internet Protocol" E il protocollo che viene seguito per trasmettere un pacchetto da un host a un altro, in

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

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

Brochure prodotto Infrastrutture di ricarica per veicoli elettrici Servizi di connessione ABB

Brochure prodotto Infrastrutture di ricarica per veicoli elettrici Servizi di connessione ABB Brochure prodotto Infrastrutture di ricarica per veicoli elettrici Servizi di connessione ABB Servizi di connessione Prodotti a supporto del business Per sfruttare al meglio una rete di ricarica per veicoli

Dettagli

SISTEMI OPERATIVI DISTRIBUITI

SISTEMI OPERATIVI DISTRIBUITI SISTEMI OPERATIVI DISTRIBUITI E FILE SYSTEM DISTRIBUITI 12.1 Sistemi Distribuiti Sistemi operativi di rete Sistemi operativi distribuiti Robustezza File system distribuiti Naming e Trasparenza Caching

Dettagli

Web Services. Scoperta del servizio UDDI. Descrizione del servizio WSDL. Accesso al servizio SOAP XML. Starto di comunicazione HTTP

Web Services. Scoperta del servizio UDDI. Descrizione del servizio WSDL. Accesso al servizio SOAP XML. Starto di comunicazione HTTP Web Services I web services servono a rendere interoperabili le applicazioni e favoriscono la loro integrazione. I servizi web sono applicazioni software che possono essere scoperte, descritte e usate

Dettagli

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Progettazione OO E. TINELLI Punto di Partenza Il modello di analisi E una rappresentazione minima del

Dettagli

UML e (R)UP (an overview)

UML e (R)UP (an overview) Lo sviluppo di sistemi OO UML e (R)UP (an overview) http://www.rational.com http://www.omg.org 1 Riassumento UML E un insieme di notazioni diagrammatiche che, utilizzate congiuntamente, consentono di descrivere/modellare

Dettagli

Integrazione di Sistemi Informativi Sanitari attraverso l uso di Middleware Web Services

Integrazione di Sistemi Informativi Sanitari attraverso l uso di Middleware Web Services Consiglio Nazionale delle Ricerche Istituto di Calcolo e Reti ad Alte Prestazioni Integrazione di Sistemi Informativi Sanitari attraverso l uso di Middleware Web Services I. Marra M. Ciampi RT-ICAR-NA-06-04

Dettagli

Internet Architettura del www

Internet Architettura del www Internet Architettura del www Internet è una rete di computer. Il World Wide Web è l insieme di servizi che si basa sull architettura di internet. In una rete, ogni nodo (detto host) è connesso a tutti

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

Introduzione. Livello applicativo Principi delle applicazioni di rete. Stack protocollare Gerarchia di protocolli Servizi e primitive di servizio 2-1

Introduzione. Livello applicativo Principi delle applicazioni di rete. Stack protocollare Gerarchia di protocolli Servizi e primitive di servizio 2-1 Introduzione Stack protocollare Gerarchia di protocolli Servizi e primitive di servizio Livello applicativo Principi delle applicazioni di rete 2-1 Pila di protocolli Internet Software applicazione: di

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

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

Rational Unified Process Introduzione

Rational Unified Process Introduzione Rational Unified Process Introduzione G.Raiss - A.Apolloni - 4 maggio 2001 1 Cosa è E un processo di sviluppo definito da Booch, Rumbaugh, Jacobson (autori dell Unified Modeling Language). Il RUP è un

Dettagli

Introduzione all elaborazione di database nel Web

Introduzione all elaborazione di database nel Web Introduzione all elaborazione di database nel Web Prof.ssa M. Cesa 1 Concetti base del Web Il Web è formato da computer nella rete Internet connessi fra loro in una modalità particolare che consente un

Dettagli

Seminario di Sistemi Distribuiti RPC su SOAP

Seminario di Sistemi Distribuiti RPC su SOAP Seminario di Sistemi Distribuiti RPC su SOAP Massimiliano Vivian [777775] Massimiliano Vivian 1 Introduzione La comunicazione delle informazioni è l elemento fondamentale per lo sviluppo dei sistemi. SOAP

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

TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE

TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE I.C.T. Information and Communication Technology TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI DESCRIZIONE

Dettagli

TECNOLOGIE E PROGETTAZIONE DI SISTEMI INFORMATICI E DI TELECOMUNICAZIONI

TECNOLOGIE E PROGETTAZIONE DI SISTEMI INFORMATICI E DI TELECOMUNICAZIONI TECNOLOGIE E PROGETTAZIONE DI SISTEMI INFORMATICI E DI TELECOMUNICAZIONI Confronto tra ISO-OSI e TCP/IP, con approfondimento di quest ultimo e del livello di trasporto in cui agiscono i SOCKET. TCP/IP

Dettagli

MODELLO CLIENT/SERVER. Gianluca Daino Dipartimento di Ingegneria dell Informazione Università degli Studi di Siena daino@unisi.it

MODELLO CLIENT/SERVER. Gianluca Daino Dipartimento di Ingegneria dell Informazione Università degli Studi di Siena daino@unisi.it MODELLO CLIENT/SERVER Gianluca Daino Dipartimento di Ingegneria dell Informazione Università degli Studi di Siena daino@unisi.it POSSIBILI STRUTTURE DEL SISTEMA INFORMATIVO La struttura di un sistema informativo

Dettagli

Il Paradigma REST per lo sviluppo di applicazioni Web 2.0

Il Paradigma REST per lo sviluppo di applicazioni Web 2.0 tesi di laurea Anno Accademico 2006/2007 Il Paradigma REST per lo sviluppo di applicazioni Web 2.0 relatore Ch.mo prof. Domenico Cotroneo correlatore Ing. Marcello Cinque candidato Antonio Alonzi Matr.

Dettagli

Analisi dei Requisiti

Analisi dei Requisiti Analisi dei Requisiti Pagina 1 di 16 Analisi dei Requisiti Indice 1 - INTRODUZIONE... 4 1.1 - OBIETTIVO DEL DOCUMENTO...4 1.2 - STRUTTURA DEL DOCUMENTO...4 1.3 - RIFERIMENTI...4 1.4 - STORIA DEL DOCUMENTO...4

Dettagli

SDD System design document

SDD System design document UNIVERSITA DEGLI STUDI DI PALERMO FACOLTA DI INGEGNERIA CORSO DI LAUREA IN INGEGNERIA INFORMATICA TESINA DI INGEGNERIA DEL SOFTWARE Progetto DocS (Documents Sharing) http://www.magsoft.it/progettodocs

Dettagli

POR Calabria FSE 2007/2013 Asse II Occupabilità Obiettivo operativo D1

POR Calabria FSE 2007/2013 Asse II Occupabilità Obiettivo operativo D1 Allegato n. 2 al Capitolato speciale d appalto. ENTE PUBBLICO ECONOMICO STRUMENTALE DELLA REGIONE CALABRIA POR Calabria FSE 2007/2013 Asse II Occupabilità Obiettivo operativo D1 Procedura aperta sotto

Dettagli

Implementazione di un servizio VoIP in ambienti SOA per mobile computing

Implementazione di un servizio VoIP in ambienti SOA per mobile computing tesi di laurea Implementazione di un servizio VoIP in ambienti SOA per mobile computing Anno Accademico 2006/2007 relatore Ch.mo prof. Domenico Cotroneo correlatore ing. Marcello Cinque candidato Vittorio

Dettagli

7.1 Livello di completezza degli esempi

7.1 Livello di completezza degli esempi Luca Cabibbo Analisi e Progettazione del Software Capitolo 7 marzo 2013 Buono, poco costoso, rapidamente. Puoi scegliere due di queste caratteristiche. Anonimo 1 *** AVVERTENZA *** I lucidi messi a disposizione

Dettagli

UNIVERSITÀ DEGLI STUDI DI FIRENZE FACOLTA DI INGEGNERIA DIPARTIMENTO DI SISTEMI E INFORMATICA. Elaborato di Tecnologie del Software per Internet

UNIVERSITÀ DEGLI STUDI DI FIRENZE FACOLTA DI INGEGNERIA DIPARTIMENTO DI SISTEMI E INFORMATICA. Elaborato di Tecnologie del Software per Internet UNIVERSITÀ DEGLI STUDI DI FIRENZE FACOLTA DI INGEGNERIA DIPARTIMENTO DI SISTEMI E INFORMATICA Elaborato di Tecnologie del Software per Internet JMSWEB 2 SISTEMA PER LO SCAMBIO DI MESSAGGI TRA APPLICAZIONI

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

Il progetto di ricerca Ellade

Il progetto di ricerca Ellade Il progetto di ricerca Ellade Ellade ELectronic Live ADaptive Learning Gruppo di lavoro Università degli Studi della Calabria, Dipartimento di Matematica Università degli Studi Mediterranea di Reggio Calabria,

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

Principi dell ingegneria del software Relazioni fra

Principi dell ingegneria del software Relazioni fra Sommario Principi dell ingegneria del software Leggere Cap. 3 Ghezzi et al. Principi dell ingegneria del software Relazioni fra Principi Metodi e tecniche Metodologie Strumenti Descrizione dei principi

Dettagli

Centro Nazionale per l Informatica nella Pubblica Amministrazione. Gara a procedura aperta n. 1/2007. per l appalto dei

Centro Nazionale per l Informatica nella Pubblica Amministrazione. Gara a procedura aperta n. 1/2007. per l appalto dei Centro Nazionale per l Informatica nella Pubblica Amministrazione Gara a procedura aperta n. 1/2007 per l appalto dei Servizi di rilevazione e valutazione sullo stato di attuazione della normativa vigente

Dettagli

Il File System. È la componente del S.O. che si occupa della gestione della memoria di massa e dell organizzazione logica dei dati

Il File System. È la componente del S.O. che si occupa della gestione della memoria di massa e dell organizzazione logica dei dati Il File System È la componente del S.O. che si occupa della gestione della memoria di massa e dell organizzazione logica dei dati Le operazioni supportate da un file system sono: eliminazione di dati modifica

Dettagli

MetaMAG METAMAG 1 IL PRODOTTO

MetaMAG METAMAG 1 IL PRODOTTO METAMAG 1 IL PRODOTTO Metamag è un prodotto che permette l acquisizione, l importazione, l analisi e la catalogazione di oggetti digitali per materiale documentale (quali immagini oppure file di testo

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

UDP. Livello di Trasporto. Demultiplexing dei Messaggi. Esempio di Demultiplexing

UDP. Livello di Trasporto. Demultiplexing dei Messaggi. Esempio di Demultiplexing a.a. 2002/03 Livello di Trasporto UDP Descrive la comunicazione tra due dispositivi Fornisce un meccanismo per il trasferimento di dati tra sistemi terminali (end user) Prof. Vincenzo Auletta auletta@dia.unisa.it

Dettagli

Internet e protocollo TCP/IP

Internet e protocollo TCP/IP Internet e protocollo TCP/IP Internet Nata dalla fusione di reti di agenzie governative americane (ARPANET) e reti di università E una rete di reti, di scala planetaria, pubblica, a commutazione di pacchetto

Dettagli

Appunti di Sistemi Distribuiti

Appunti di Sistemi Distribuiti Appunti di Sistemi Distribuiti Matteo Gianello 27 settembre 2013 1 Indice 1 Introduzione 3 1.1 Definizione di sistema distribuito........................... 3 1.2 Obiettivi.........................................

Dettagli

Un applicazione client per la localizzazione via Bluetooth e Wi-Fi di dispositivi Smartphone Anno Accademico 2005/2006

Un applicazione client per la localizzazione via Bluetooth e Wi-Fi di dispositivi Smartphone Anno Accademico 2005/2006 tesi di laurea Un applicazione client per la localizzazione via Bluetooth e Wi-Fi di dispositivi Anno Accademico 2005/2006 relatore Ch.mo prof. Stefano Russo correlatore Ing. Massimo Ficco candidato Giorgio

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

La specifica del problema

La specifica del problema 2.9 (Caso di studio facoltativo) Pensare a oggetti: esame del problema Iniziamo ora a esaminare il nostro caso di studio di progettazione e implementazione orientate agli oggetti. Le sezioni Pensare a

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

Modellazione di sistema

Modellazione di sistema Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Modellazione di sistema E. TINELLI Contenuti Approcci di analisi Linguaggi di specifica Modelli di

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

SISTEMI E RETI 4(2) 4(2) 4(2) caratteristiche funzionali

SISTEMI E RETI 4(2) 4(2) 4(2) caratteristiche funzionali CL AS SE INFORMATICA 6(3) 6(4) - 6(4) SISTEMI E RETI 4(2) 4(2) 4(2) TECNOLOGIE E PROGETTAZIONE DI SISTEMI INFORMATICI E DI TELECOMUNICAZIONI COMPETENZE 3 Essere in grado di sviluppare semplici applicazioni

Dettagli

Strategie di system integration per l interoperabilità di sistemi eterogenei di Fascicolo Sanitario Elettronico

Strategie di system integration per l interoperabilità di sistemi eterogenei di Fascicolo Sanitario Elettronico Consiglio Nazionale delle Ricerche Istituto di Calcolo e Reti ad Alte Prestazioni Strategie di system integration per l interoperabilità di sistemi eterogenei di Fascicolo Sanitario Elettronico Mario Ciampi

Dettagli

Approfondimento. Web Services

Approfondimento. Web Services Approfondimento Web Services Esame di Programmazione per il Web Fedele Ladisa INDICE Capitolo 1. Introduzione 1.1 Introduzione ai Web Services 1.2 Architettura dei Web Services 1.3 Stack protocollare di

Dettagli

D3.2 Documento illustrante l architettura 3D Cloud per la realizzazione di servizi in modalità SaaS

D3.2 Documento illustrante l architettura 3D Cloud per la realizzazione di servizi in modalità SaaS D3.2 Documento illustrante l architettura 3D Cloud per la realizzazione di servizi in modalità SaaS Il modello SaaS Architettura 3D Cloud Il protocollo DCV Benefici Il portale Web EnginFrame EnginFrame

Dettagli

Laboratorio di Informatica I

Laboratorio di Informatica I Struttura della lezione Lezione 1: Le Architetture Distribuite Vittorio Scarano Algoritmi e Strutture Dati: Algoritmi Distribuiti Corso di Laurea in Informatica Università di Salerno Le architetture distribuite

Dettagli

Reti e Internet: introduzione

Reti e Internet: introduzione Facoltà di Medicina - Corso di Laurea in Logopedia Corso di Informatica III anno Prof. Crescenzio Gallo Reti e Internet: introduzione c.gallo@unifg.it Reti e Internet: argomenti Tipologie di reti Rete

Dettagli

Università degli studi di Ferrara. Sviluppo di un Web Service per la classificazione del suolo e sua integrazione sul Portale SSE

Università degli studi di Ferrara. Sviluppo di un Web Service per la classificazione del suolo e sua integrazione sul Portale SSE Università degli studi di Ferrara Facoltà di scienze MM.FF.NN. Corso di Laurea Specialistica in Informatica Sviluppo di un Web Service per la classificazione del suolo e sua integrazione sul Portale SSE

Dettagli

Architettura del sistema

Architettura del sistema 18/06/15 I N D I C E 1 INTRODUZIONE... 2 2 DEFINIZIONE DEGLI OBIETTIVI... 2 3 PROGETTO DI MASSIMA... 3 3.1 REQUISITI DELLA SOLUZIONE... 4 4 LA SOLUZIONE... 4 4.1 IL NUCLEO CENTRALE... 5 4.1.1 La gestione

Dettagli

Web Services con Axis Delia Di Giorgio Anna Celada 1 marzo 2005

Web Services con Axis Delia Di Giorgio Anna Celada 1 marzo 2005 Sommario Web Services con Axis Delia Di Giorgio Anna Celada 1 marzo 2005 Introduzione.................................................................................. 1 SOAP........................................................................................

Dettagli

Sommario. Introduzione... xvii. 1 Che cosa sono i servizi Web?... 1

Sommario. Introduzione... xvii. 1 Che cosa sono i servizi Web?... 1 Sommario Introduzione................................................... xvii Benvenuti!......................................................... xvii Questo libro fa al caso vostro?..........................................

Dettagli

Java Enterprise Edi.on. Gabriele Tolomei DAIS Università Ca Foscari Venezia

Java Enterprise Edi.on. Gabriele Tolomei DAIS Università Ca Foscari Venezia Java Enterprise Edi.on Gabriele Tolomei DAIS Università Ca Foscari Venezia Java Web Services Web Services: SOAP vs. RESTful 2 diversi.pi di Web Services I Web Services SOAP sono quelli classici Si basano

Dettagli

Architetture Applicative

Architetture Applicative Alessandro Martinelli alessandro.martinelli@unipv.it 6 Marzo 2012 Architetture Architetture Applicative Introduzione Alcuni esempi di Architetture Applicative Architetture con più Applicazioni Architetture

Dettagli

7. Architetture Software

7. Architetture Software 7. Architetture Software progettare la struttura Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 7. Architetture Software 1 / 20 Scopo della fase di design

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

Programmazione Web. Introduzione

Programmazione Web. Introduzione Programmazione Web Introduzione 2014/2015 1 Un'applicazione Web (I) 2014/2015 Programmazione Web - Introduzione 2 Un'applicazione Web (II) 2014/2015 Programmazione Web - Introduzione 3 Un'applicazione

Dettagli

Sviluppo di applicazioni Internet: l'uso integrato di XML e Java

Sviluppo di applicazioni Internet: l'uso integrato di XML e Java UNIVERSITA' DEGLI STUDI DI MODENA E REGGIO EMILIA Facoltà di Ingegneria - Sede di Modena Corso di Laurea in Ingegneria Infomatica Sviluppo di applicazioni Internet: l'uso integrato di XML e Java realizzata

Dettagli

Siti web centrati sui dati (Data-centric web applications)

Siti web centrati sui dati (Data-centric web applications) Siti web centrati sui dati (Data-centric web applications) 1 A L B E R T O B E L U S S I A N N O A C C A D E M I C O 2 0 1 2 / 2 0 1 3 WEB La tecnologia del World Wide Web (WWW) costituisce attualmente

Dettagli

Strumenti di modellazione. Gabriella Trucco

Strumenti di modellazione. Gabriella Trucco Strumenti di modellazione Gabriella Trucco Linguaggio di modellazione Linguaggio formale che può essere utilizzato per descrivere (modellare) un sistema Il concetto trova applicazione soprattutto nell

Dettagli

WEBsfa: l automazione della forza vendita via Web

WEBsfa: l automazione della forza vendita via Web WEBsfa: l automazione della forza vendita via Web White Paper 1 Gennaio 2005 White Paper Pag. 1 1/1/2005 L automazione della Forza Vendita Le aziende commerciali che che sviluppano e alimentano il proprio

Dettagli

Architettura del. Sintesi dei livelli di rete. Livelli di trasporto e inferiori (Livelli 1-4)

Architettura del. Sintesi dei livelli di rete. Livelli di trasporto e inferiori (Livelli 1-4) Architettura del WWW World Wide Web Sintesi dei livelli di rete Livelli di trasporto e inferiori (Livelli 1-4) - Connessione fisica - Trasmissione dei pacchetti ( IP ) - Affidabilità della comunicazione

Dettagli

Indirizzi Internet e. I livelli di trasporto delle informazioni. Comunicazione e naming in Internet

Indirizzi Internet e. I livelli di trasporto delle informazioni. Comunicazione e naming in Internet Indirizzi Internet e Protocolli I livelli di trasporto delle informazioni Comunicazione e naming in Internet Tre nuovi standard Sistema di indirizzamento delle risorse (URL) Linguaggio HTML Protocollo

Dettagli

Object Oriented Programming

Object Oriented Programming OOP Object Oriented Programming Programmazione orientata agli oggetti La programmazione orientata agli oggetti (Object Oriented Programming) è un paradigma di programmazione Permette di raggruppare in

Dettagli

1 Progetto di laboratorio di reti I

1 Progetto di laboratorio di reti I 1 Progetto di laboratorio di reti I In questo documento sono descritte le specifiche per la realizzazione del progetto. Vedremo innanzitutto le caratteristiche richieste nel codice e nella relazione, per

Dettagli

Applicazione: GAS - Gestione AcceSsi

Applicazione: GAS - Gestione AcceSsi Riusabilità del software - Catalogo delle applicazioni Gestione ICT Applicazione: GAS - Gestione AcceSsi Amministrazione: Consiglio Nazionale delle Ricerche (CNR) Responsabile dei sistemi informativi Nome

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 di Napoli Federico II. FACOLTÀ DI INGEGNERIA Corso di Laurea in Ingegneria Informatica LM. Progetto di un applicazione Android

Università degli Studi di Napoli Federico II. FACOLTÀ DI INGEGNERIA Corso di Laurea in Ingegneria Informatica LM. Progetto di un applicazione Android Università degli Studi di Napoli Federico II FACOLTÀ DI INGEGNERIA Corso di Laurea in Ingegneria Informatica LM Progetto di un applicazione Android Briscola bluetooth Candidati: Giuliano Formato Daniele

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

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

DATABASE IN RETE E PROGRAMMAZIONE LATO SERVER

DATABASE IN RETE E PROGRAMMAZIONE LATO SERVER DATABASE IN RETE E PROGRAMMAZIONE LATO SERVER L architettura CLIENT SERVER è l architettura standard dei sistemi di rete, dove i computer detti SERVER forniscono servizi, e computer detti CLIENT, richiedono

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