Global Weather Web Service

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Global Weather Web Service"

Transcript

1 Corso di Laurea Specialistica in Informatica Global Weather Web Service Matr A.A /99

2 Premessa La presente documentazione viene redatta come progetto conclusivo del corso di Laboratorio di Sistemi Distribuiti del corso di Laurea Specialistica in Informatica dell'università di Roma Tor Vergata, svolto nell'a.a Sulla base di tali premesse è stata sviluppata una Web Application basata su tecnologie Web Service denominata Global Weather, la quale, come si può intuire dal nominativo scelto, fornisce le previsioni meteorologiche di una data città, previa selezione della nazione di appartenenza, i cui valori delle misure rilevate vengono appositamente convertite da MP/H a KM/H. Al fine di meglio strutturare la documentazione di tale applicazione, si è deciso di strutturare l'argomentazione nei seguenti capitoli: Capitolo 1 : introduzione al concetto di architettura orientata ai servizi (SOA); Capitolo 2 : presentazione del modello Web Service, quale implementazione di un modello SOA su rete Internet; Capitolo 3 : presentazione delle tecnologie utilizzate per l'implementazione del Web Service Global Weather; Capitolo 4 : documentazione UML dell'applicazione Global Weather. 2/99

3 Indice generale Premessa... 2 Introduzione...5 1SOA: Service-Oriented Architecture Introduzione Caratteristiche di una SOA Come funziona una SOA I Web Service Introduzione Scenari Complessi Tecnologie XML Struttura di un documento XML DTD: Document Type Definition XML Schema Namespece XML Lavorare con i documenti XML Elaborazione tramite SAX Elaborazione tramite DOM Il protocollo SOAP Il messaggio SOAP e modelli di scambio Utilizzo dell intestazione Gestione degli Errori SOAP su HTTP SOAP e RPC SOAP Encoding SOAP con Allegati SOAP e Java Il linguaggio WSDL L'elemento Type L'elemento Message L'elemento PortType L'elemento Binding L'elemento Service Il protocollo UDDI Il contesto architetturale di UDDI I ruoli in UDDI Il registro UDDI Rappresentazione delle informazioni in UDDI Struttura di UDDI Interazioni con UDDI Esempio Tecnologie per Web Services di seconda generazione Web Services : tecnologie Introduzione Java TomCat Axis L'architettura di Axis Installazione di AXIS Deployment di Web Service su Axis Strumenti per il monitoraggio delle comunicazioni MySQL /99

4 3.6jUDDI Installazione di juddi UDDI4J Installazione di UDDI4J Tecniche di invocazione di Web Service Stub creato da WSDL Dynamic Proxy Dynamic Invocation Interface (DII) Dynamic Discovery and Invocation (DDI) Global Weather Web Service Introduzione Il Workflow Class Diagram Class Diagram del presentation layer Class Diagram della business logic Class Diagram del meteo fornito dal Web Service fittizio Class Diagram del Web Service di conversione Use Cases Use Case Scelta Nazione Use Case Scelta Città Use Case Previsioni Meteorologiche Sequence Diagram Sequence Diagram per la richiesta dell'elenco città Sequence Diagram per la richiesta delle previsioni meteorologiche espresse in MPH Sequence Diagram per la richiesta delle previsioni meteorologiche espresse in KMH Bigliogragia /99

5 Introduzione Spiegare cosa sia il Web 2.0, ovvero cosa si nasconda dietro tale termine, è cosa veramente ardua,. Questo perché oggi siamo di fronte più ad un cambiamento culturale che ad un'innovazione tecnologica vera e propria come era stata Internet anni fa, possiamo dire oramai nella versione 1.0, ovvero nell'oramai ex epoca della new economy, e sopratutto perché in linea di massima noi informatici diventiamo matti quando una cosa è eterna e soprattutto siamo caratterizzati dal naturale istinto di incatenare una definizione ad espressioni logiche (1.0, 1.03, 2.0beta, e così via). Ad onor del merito, la paternità del termine è da attribuire a Tim O'Reilly, il quale coniò il termine, verso la metà del 2004, durante una sessione di brainstorming volta a definire il tema di una nuova conferenza sul Web. In un primo momento l'idea di Tim O'Reilly fu oggetto di un aspro dibattito, sui primi WebLog del tempo, tanto da far nascere una querelle tra lui e Tim Bray, inventore dell'xml, il quale in un suo post intitolato NOT 2.0, ha dichiarato che l'espressione Web 2.0 era riconducibile a una vuota operazione di marketing che richiamava i fantasmi della bolla. Da quel momento, il termine new economy venne definitivamente sepolto e sostituito dal nuovo slogan Web 2.0, il cui significato possiamo trovarlo anche su Wikipedia1, quale massimo rappresentante della tecnologia proposta: Web 2.0 è un termine coniato da Tim O'Reilly e Dale Dougherty (della O'relly Media, casa editrice americana specializzata in pubblicazioni riguardanti le nuove tecnologie ed Internet in particolare) nel 2004 e fa riferimento ai cosiddetti servizi Internet di seconda generazione quali siti di social networking, wiki2, strumenti di comunicazione e folksonomy3 che enfatizzano la collaborazione e la condivisione tra utenti Tale definizione, ovviamente non è da considerarsi di carattere esaustivo, soprattuto poiché Wikipedia, come tutti i servizi basati sui contenuti liberamente generati dagli utenti nel Web 2.0, ha il problema della fondamentale, ovvero l'anarchia dei contributi, potenzialmente a scapito di 1 2 Un wiki è un sito Web gestito da un sistema che permette a ciascuno dei suoi utilizzatori di aggiungere contenuti, ma anche di modificare i contenuti esistenti inseriti da altri utilizzatori. 3 È un neologismo che descrive una categorizzazione collaborativa di informazioni mediante l'utilizzo di parole chiave, dette tag, scelte liberamente. 5/99

6 qualità, etica e consapevolezza. Il Web 2.0 non è solo una nuova tecnologia o un nuovo insieme di tecnologie e non è solo un cambiamento culturale di approccio alla Rete. Tecnologia e società sono le vere basi del Web 2.0 che, con pieno titolo, può essere definito un movimento. La componente tecnologica ha in sé anche la componente sociale in quanto nel Web 2.0 non ci si trova di fronte a nuove scoperte o nuove tecnologie ma piuttosto si assiste all'affermazione e alla diffusione significativa nell'ambito delle comunità tecnologiche, di sviluppatori e di architetti applicativi, di tecnologie che consentono di abilitare un utilizzo della Rete incentrato sulla persona e sugli aspetti sociali (networking effect). Sicuramente i tecnici più conservatori storceranno il naso nei confronti di tali affermazioni, sicuramente affermeranno che: non siamo di fronte ad un'evoluzione tecnologica dei protocolli TCP/IP e ne tanto meno protocolli come l'ipv64 sono ancora lontani dall'adozione di massa; il termine Web 2.0, può ritenersi limitativo in quanto, tecnologicamente parlando, l'evoluzione va oltre i confini della Rete intesa come World Wide Web. L'affermazione di servizi oltre il Web come per esempio VoIP5, il cui esempio più eclatante è il fenomeno Skype, il podcasting, il Web Mobile e video e il fenomeno del peer to peer per file sharing, suggeriscono che sarebbe più corretto definirlo Internet 2.0. Le potenziali contestazioni che possono essere sollevate, vengono meno quando questi singoli componenti tecnologici vengono gestiti dalla componente sociale, intesa come aspetto di interazione sociale e il cambiamento di approccio il quale varia dalla consultazione, intesa come ricerca clic, lettura di informazione su siti e portali, al contributo ed alla partecipazione sul Web sono possibili solo grazie alla diffusione e adozione della tecnologia informatica su larga scala, vero fattore abilitante della collaborazione tra utenti della condivisione di informazioni, dati e processi di lavoro, sia a livello culturale che professionale. Pertanto, volendo classificare e schematizzare le caratteristiche del Web 2.0 si può far riferimento a quattro elementi principali, il cui sviluppo può essere considerato causa degli altri: 1. Technology. Ampia diffusione e utilizzo avanzato di tecnologie quali AJAX 6, API, Peer-toPeer, RSS7, XML e Web Service a supporto dell'utente che utilizza, plasma, modifica un servizio bidirezionale, un'applicazione e non naviga semplicemente in un sito. 2. User Experience. L'utilizzo di tecnologie come AJAX consente di realizzare un'esperienza utente nell'utilizzo delle applicazioni Web su Internet e di siti paragonabile a quella dell'utilizzo di un'applicazione che gira sulla macchina locale. 4 Internet Protocol version 6, è un'evoluzione-rivoluzione dell'attuale protocollo IP alla base dello stack TCP/IP comunemente usato. Esso introduce alcuni nuovi servizi e semplifica molto la configurazione e la gestione delle reti IP. La sua caratteristica più appariscente è il più ampio spazio di indirizzamento: IPv6 gestisce fino a circa 3, indirizzi, mentre IPv4 gestisce soltanto fino a circa 4 miliardi (4 109) di indirizzi. 5 Voice over Internet Protocol, è una tecnologia che rende possibile effettuare una conversazione telefonica sfruttando una connessione Internet o un'altra rete dedicata che utilizza il protocollo IP, anziché passare attraverso la rete telefonica tradizionale (PSTN). Ciò consente di eliminare le relative centrali di commutazione e di economizzare sulla larghezza di banda occupata. Vengono instradati sulla rete pacchetti di dati contenenti le informazioni vocali, codificati in forma digitale, e ciò solo nel momento in cui è necessario, cioè quando uno degli utenti collegati sta parlando. 6 AJAX, acronimo di Asynchronous JavaScript and XML, è una tecnica di sviluppo web per creare applicazioni web interattive. L'intento di tale tecnica è quello di ottenere pagine web che rispondono in maniera più rapida, grazie allo scambio in background di piccoli pacchetti di dati con il server, così che l'intera pagina web non debba essere ricaricata ogni volta che l'utente effettua una modifica. Questa tecnica riesce, quindi, a migliorare l'interattività, la velocità e l'usabilità di una pagina web. 7 RSS, acronimo di RDF Site Summary ed anche di Really Simple Syndication, è uno dei più popolari formati per la distribuzione di contenuti Web; è basato su XML, da cui ha ereditato la semplicità, l'estensibilità e la flessibilità. RSS definisce una struttura adatta a contenere un insieme di notizie, ciascuna delle quali sarà composta da vari campi (nome autore, titolo, testo, riassunto,...). Quando si pubblicano delle notizie in formato RSS, la struttura viene aggiornata con i nuovi dati; visto che il formato è predefinito, un qualunque lettore RSS potrà presentare in una maniera omogenea notizie provenienti dalle fonti più diverse. 6/99

7 3. Open (culture): Source, Application, Data, Content. Il fenomeno della condivisione, supportato dalla tecnologia libera e gratuita, contagia tutto: dal codice al software, dai dati alle applicazioni ai contenuti. Si affermano nuovi comportamenti di condivisione e distribuzione libera attraverso la rete di ogni cosa sia dato, informazione, immagine, video o software. 4. Social Network. Partecipazione e relazioni sociali. La tecnologia, la condivisione e l'esperienza applicativa favoriscono lo sviluppo della partecipazione a una nuova vita di community che crea sulla Rete nuove forme di intelligenza collettiva. Il comun denominatore di questi quattro elementi, è rappresentato dalle persone, che ogni giorno contribuiscono a diffondere tali tecnologie e comportamenti di massa, scrivendo codice, contenuti, blog, creando e distribuendo foto, filmati, opinioni, commenti, inviti, ma soprattutto mixando questi elementi in modi nuovi ed originali, creando innovazione tecnologica e sociale seguendo i propri istinti e passioni. Nei capitoli a seguire, concentreremo la nostra attenzione sul contesto tecnology, in particolar modo sui web service, quale implementazione fisica di un Architettura Orientata ai Servizi (SOA), fornendo in primis una loro descrizione di carattere teorico nel primo capitolo ed una loro implementazione nel successivo capitolo 2, mediante la realizzazione del servizio anzi anticipato in sede di premessa. 7/99

8 1 SOA: Service-Oriented Architecture 1.1 Introduzione Una Service-Oriented Architecture (SOA, Architettura Orientata ai Servizi) è un modello architetturale per la creazione di sistemi residenti su una rete che focalizza l attenzione sul concetto di servizio. 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: intracompany o intercompany network). Ogni servizio mette a disposizione una certa funzionalità e può utilizzare quelle che gli altri servizi hanno reso disponibili, realizzando, in questo modo, applicazioni di maggiore complessità. 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, quindi devono comunicare per mezzo di stack di protocolli hardware/software su una rete. Questo significa che le comunicazioni in un sistema distribuito sono intrinsecamente meno veloci e affidabili rispetto a quelle che utilizzano invocazione diretta del codice e memoria condivisa. Ciò 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. 1.2 Caratteristiche di una SOA L astrazione delle SOA non è legata ad alcuna specifica tecnologia, ma semplicemente definisce 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 autocontenuto 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, astraendo dai metodi e dalle tecnologie utilizzate per implementarlo. 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 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 o Service Registry) 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. fornire un interfaccia possibilmente a grana grossa (coarse-grained). Deve mettere a 8/99

9 disposizione un basso numero di operazioni, cioè poche funzionalità, in modo tale da non dover avere un programma di controllo complesso. Deve essere invece orientato ad un elevato livello di interazione 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 (Platform Neutral). 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. 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. Queste dunque le caratteristiche di un sistema di tipo SOA, di cui adesso passiamo a descrivere il funzionamento. 1.3 Come funziona una SOA Gli attori di un sistema SOA sono tre: Service Provider Service Consumer Service Registry. Il Service Provider è un entità che 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 comunica al Service Registry le informazioni relative al servizio, perché vengano memorizzate. Il Service Registry possiede quindi le informazioni, come URL e modalità di accesso, di tutti i servizi disponibili. Nel momento in cui un Service Consumer dovrà utilizzare un servizio farà richiesta delle informazioni ad esso relative al Service Registry. Con queste informazioni il Service Consumer potrà comunicare direttamente con il Service Provider ed utilizzare il servizio. In figura sono riportate le interazioni fra le entità appena descritte. Illustrazione 1.1: Esempio di Architettura SOA. Tutte queste interazioni passano attraverso quella che in figura 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. 9/99

10 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. Dopo aver descritto cos è l architettura SOA ed il funzionamento di un sistema di questo tipo, vediamo adesso cosa sono i Web Services, quali tecnologie utilizzano ed il loro legame con SOA. 10/99

11 2 I Web Service 2.1 Introduzione Promossi da società del calibro di Microsoft ed IBM, i servizi Web promettono di far integrare sistemi software in modo standard sulla rete, mediante l'impiego di protocolli e tecnologie concrete come SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) ed UDDI (Universal Description, Discovery and Integration). I Web Service sono soluzioni adottabili in contesti: Enterprise Application Integration8 (EAI) Business-to-Business9 (B2B) Business-to-Customer10 (B2C) Tale tecnologia è stata adottata in maniera ufficiale W3C 11 intorno al Dicembre del 2001, il quale ha formalizzato l'architettura con la seguente definizione: Un Web Service (o servizio web) è un sistema software progettato per supportare l interoperabilità tra diversi elaboratori su di una medesima rete; caratteristica fondamentale di un Web Service è quella di offrire un interfaccia software attraverso la quale altri sistemi possono interagire con il Web Service stesso tramite appositi messaggi: tali messaggi sono inviati tramite i protocolli di livello applicativo (HTTP, FTP, SMTP...) e formattati secondo lo standard XML. Illustrazione 2.1: Servizi Web: XML e protocolli Internet Sulla base di tali premesse, possiamo quindi affermare che la disponibilità di questi elementi sulla rete, consente potenzialmente a chiunque di interagire con componenti software offerti dalle singole aziende. Uno scenario possibile potrebbe essere quello trattato nel capitolo successivo, nel quale si costruisce una Web Application sfruttando Web Service forniti da altre società delle quali alcune comunicano l'elenco delle città di una data nazione, altre invece forniscono le previsioni meteo di una città della nazione prescelta ed infine altre società forniscono un servizio di conversione di unità di misura, come quello da MPH a KMH. Tutte queste informazioni vengono gestite in backend dal nostro sistema al fine di completare l accettazione e l evasione della richiesta di previsioni meteo, ovviamente, se uno dei servizi non fosse disponibile, la logica di back-end potrebbe ritentare l operazione chiamando il medesimo servizio implementato da un altro fornitore, garantendo così un buon livello di fault-tolerance. 8 Enterprice Application Integration : a differenza dei normali middleware che integrano i server che si trovano nello strato delle risorse, l EAI è una generalizzazione di questo funzionamento, in quanto, integra le logiche applicative di sistemi middleware. 9 Business-to-Business : insiemi di transazioni che avvengono tra ditte o società per il raggiungimento di un determinato obiettivo di business. Generalmente in questo contesto vengono realizzate applicazioni le quali spesso non hanno necessità di una vera e propria interfaccia, la quale se esiste risulta essere prevalentemente di tipo testuale. Tali tipi di applicazioni sono orientate all'utilizzo da parte di sistemi automatizzati. 10 Business-to-Customer : insiemi di transazioni che avvengono tra ditte o società ed il loro clienti. Generalmente in questo contesto vengono realizzate applicazioni ad interfaccia grafica, orientate all'utilizzo da parte di essere umani /99

12 2.2 Scenari Complessi I possibili scenari possono avere complessità diverse, a partire da quelli più banali, anche oggi realizzabili, fino ad arrivare alle ipotesi più fantasiose, dove i flussi di lavoro non sono altro che aggregazioni di singole componenti realizzate da servizi Web. Nelle ipotesi più elaborate, i singoli sistemi software dovrebbero essere in grado di ricercare i servizi all interno di appositi registri mondiali, che si dovrebbero occupare di realizzare il punto di incontro tra cliente e fornitore. Riprendendo l esempio precedente, l applicazione potrebbe utilizzare i registri di servizi Web per individuare tutti i potenziali fornitori di un tipo di servizio. Ad esempio, l applicazione potrebbe aver bisogno di ottenere l'elenco delle città di una data nazione, ma non sapere chi fornisce questa tipologia di servizio. A questo punto l applicazione può: 1. accedere ad uno o più registri; 2. localizzare il servizio richiesto; 3. scaricare le informazioni tecniche che consentono la sua chiamata; 4. ingaggiare il servizio. S e r v ic e R e g is tr y S c o p re W S D L U D D I R e g is t r y S e r v ic e C o n s u m e r S e r v ic e P r o v id e r SO AP A p p lic a t R e g is t r a W S D L C o d ic e Im p l P ro x y S e r v ic e C o n tr a c t Illustrazione 2.2: Workflow operativo che coinvolge registridi servizi Web Inoltre, le componenti ingaggiate potrebbero essere molteplici, in modo da costituire un workflow complesso di singoli elementi dallo scopo limitato e ben definito. Come un algoritmo svolge il suo lavoro chiamando le singole routine e gestendo opportunamente i valori di ritorno per implementare la logica richiesta, un workflow di servizi Web compone, anche in modo dinamico, singoli Web Services in modo da ottenere la funzionalità richiesta. Essendo per loro natura distribuiti, nelle tecnologie orientate ai servizi Web assumono una grande importanza le problematiche classiche presenti nella programmazione distribuita classica, dove giocano un ruolo determinante tecnologie come CORBA (Common Object Request Broker Architecture) e RMI (Remote Method Invocation), ma anche RPC (Remote Procedure Call) e DCOM (Distributed Component Object Model). I servizi web hanno però una serie di sostanziali differenze rispetto alle altre tecnologie distribuite: utilizzano un protocollo testuale (XML) al posto di quello binario costruito ad hoc, sfruttano le infrastrutture applicative già presenti di Internet (HTTP, FTP, SMTP), non hanno ancora però prodotti e tecnologie così definiti come i loro concorrenti di più lunga data. Particolare rilevanza ha in quest ambito la gestione delle transazioni: si ipotizzi che la richiesta dell'elenco delle città di una data nazione non vada a buon fine, il sistema deve evitare lo stallo dei flussi informativi, gestendo eventualmente anche un roll-back distribuito delle varie richieste effettuate ai diversi fornitori di servizi. 12/99

13 2.3 Tecnologie La visione dei Web Service è supportata da una serie di tecnologie sviluppate in fase iniziale dalle maggiori aziende del settore, talvolta come membri di un consorzio. Alcune tecnologie sono comunemente accettate, altre sono più conosciute, mentre altre ancora sono proposte di singole aziende che non è chiaro se avranno successo in futuro. Uno stack di tecnologie consolidato è presente nell'illustrazione 3. Illustrazione 2.3: Pila concettuale dei Web Service Di queste: Protocolli di Livello Applicativo. Il protocollo di trasporto preferito per lo scambio di messaggi applicativi, ed il più utilizzato, è HTTP/HTTPS anche se sarebbe possibile utilizzarne altri, come FTP e SMTP; XML. È un meta linguaggio utilizzato per creare nuovi linguaggi, atti a descrivere documenti strutturati. SOAP. È il protocollo XML di scambio dei messaggi che consente la programmazione distribuita dei servizi Web; WSDL. Consente di descrivere il servizio tramite un documento XML, in modo similare la linguaggio IDL (Interface Description Language) di CORBA; UDDI. È un servizio di directory che consente agli utenti di localizzare i servizi Web. 2.4 XML XML extensible Markup Language, è un linguaggio, indipendente dai sistemi e dall'hardware, che permette di descrivere dei dati e la loro struttura all'interno di un documento XML, ovvero di un file di testo UNICODE che contiene i dati e gli elementi di markup che definiscono la struttura dei dati stessi. Il markup XML assomiglia a quello del linguaggio HTML, in quanto consiste in un tag e attributi aggiunti ai dati all'interno del file di testo. La somiglianza apparente tra XML e HTML si limita comunque al loro aspetto superficiale: infatti XML e HTML sono profondamente differenti, sia per il loro scopo sia che per la loro capacità. Prima di tutto, sebbene un documento XML possa essere creato, letto e compreso da una persona, il suo scopo primario consiste nella comunicazione di dati da un computer all'altro. Di conseguenza, accade frequentemente che i documenti XML vengano generati ed elaborati da un programma e non da un utente umano, anche se quest'ultimi sia in grado di farlo. Un documento XML definisce la struttura dei dati contenuti al suo interno in modo che un programma che lo riceve sia in grado di interpretarlo. È quindi possibile affermare che XML è uno strumento per trasferire informazioni e la 13/99

14 loro organizzazione da un programma all'altro. Lo scopo di HTML, dall'altra parte, consiste essenzialmente nel fornire la descrizione di come i dati dovranno apparire quando vengono visualizzati o stampati. Infatti le uniche informazioni strutturali che solitamente appaiono nei documenti HTML sono relative all'aspetto dei dati dal punto di vista visivo. In secondo luogo, HTML fornisce un insieme di tag essenzialmente prefissato e dedicato principalmente alla presentazione dei dati, invece, XML è un linguaggio tramite il quale è possibile definire nuovi insiemi di tag e attributi adatti a svariate tipologie di dati, anche di tipo personalizzato. Naturalmente, una volta inventato un insieme di elementi di markup XML adatti a descrivere un tipo particolare di dato, sarà necessario rendere disponibile le regole per interpretare documenti XML di quel tipo, in modo tale da poterli creare, leggere o modificare. La definizione di tali elementi di markup utilizzati all'interno di un documento XML può essere inclusa direttamente all'interno del documento, oppure sotto forma di un'entità separata come, ad esempio, un file identificato da un URI, che possa essere referenziato all'interno di ogni documento di quel particolare tipo. Da un punto di vista implementativo, il linguaggio di programmazione Java, mette a disposizione la libreria JAXP (Java API for XML Processing) la quale fornisce strumenti necessari per leggere, creare e modificare documenti XML dall'interno dei nostri programmi. Per comprendere ed utilizzare queste API, l'utente dovrebbe però acquisire una ragionevole familiarità oltre che con i concetti fino ad ora esposti, anche il concetto di namespece XML, il quale verrà illustrato nel paragrafo a seguire Struttura di un documento XML Un documento XML può essere suddiviso in due porzioni, il prologo ed il corpo del documento detto anche body. Illustrazione 2.4: Struttura logica di un file XML il prologo fornisce le informazioni necessarie per interpretare il contenuto del corpo del documento. Esso contiene due componenti opzionali: dato che entrambi possono essere omessi, ne consegue che anche il prologo stesso è opzionale. Le due componenti del prologo, nella sequenza in cui devono apparire sono: una XML declaration che definisce la versione XML, applicabile al documento, e che può inoltre specificare quale sia la particolare codifica UNICODE per i caratteri utilizzata nel documento e se il documento stesso è di tipo standalone oppure no. Una document type declaration che specifica quale sia la DTD 12 esterna che fornisce le 12 Document Type Definition : è un documento nel quale vengono definite le regole mediante le quali si assicura che i vari dati vengano rappresentati in maniera consistente e corretta all'interno di documenti differenti. 14/99

15 dichiarazioni degli elementi di markup utilizzati nel corpo del documento, oppure fornisce esplicitamente tali dichiarazioni, o infine che svolge entrambe le funzioni. Il body contiene i dati del documento stesso, costituito da uno o più elementi, ognuno dei quali è definito da un tag d'inizio ed un tag di fine. Esiste sempre un singolo elemento root che contiene tutti gli elementi. <?xml version="1.0" encoding="utf-16"?> <CurrentWeather> <!-- questa è il root tag --> <Location>Roma / Urbe, Italy (LIRU) 41-57N E 24M</Location> <Time>Jun 20, :50 AM EDT / UTC</Time> <Wind> from the WSW (240 degrees) at 10 MPH (9 KT):0</Wind> <Visibility> greater than 7 mile(s):0</visibility> <SkyConditions> mostly clear</skyconditions> <Temperature> 69 F (21 C)</Temperature> <DewPoint> 60 F (16 C)</DewPoint> <RelativeHumidity> 73%</RelativeHumidity> <Pressure> in. Hg (1015 hpa)</pressure> <Status>Success</Status> </CurrentWeather> Listato Un semplice esempio di messaggio XML Un documento XML viene detto ben formattato quando rispetta le regole di scrittura dei documenti XML, definite dalle relative specifiche. Essenzialmente un documento XML risulta ben formattato se il suo prologo ed il suo corpo sono compatibili con le regole di base alle quali essi devono essere scritti. Un XML processor è un modulo software utilizzato da un'applicazione per leggere un documento XML, oltre che ottenere accesso ai dati contenuti al suo interno e allo loro struttura. Un XML processor determina inoltre se un documento XML sia o meno ben formattato DTD: Document Type Definition Una Document Type Definition è un file in cui è riportata la definizione di tutti gli elementi, e dei loro attributi, usati nel documento XML, specificando inoltre la correlazione tra di essi. Tale file permette ad un applicazione di sapere se il documento XML che sta analizzando è corretto o no, dato che gli elementi, essendo stati creati dallo sviluppatore, risulterebbero privi di significato senza una loro definizione. Una DTD definisce quindi la struttura di un particolare tipo di documento XML, rispetto al quale si può valutare la conformità di una data istanza XML. Le DTD, primo strumento di questo genere, presentano però delle limitazioni: possiedono una sintassi complessa (non sono scritte in XML), non permettono di specificare tipi di dato e sono difficilmente estendibili XML Schema Uno strumento, creato allo stesso scopo delle DTD, che supera le limitazioni di queste ultime è XML-Schema. Un documento XML-schema definisce: gli elementi e gli attributi che possono comparire in un documento; 15/99

16 quali elementi sono elementi figlio; l ordine ed il numero degli elementi figlio; se un elemento è vuoto o può includere testo; i tipi di dato per gli elementi e gli attributi; i valori di default ed i valori costanti per gli elementi e gli attributi. Rispetto alle DTD, gli XML-Schema sono estensibili e scritti in XML, rendono possibile la definizione di tipi di dato e di vincoli, ammettono l ereditarietà e supportano i namespace Namespece XML In precedenza è stato affermato che un documento XML permette di identificare una DTD esterna tramite un URI, di includere dichiarazioni di marckup esplicite o di fare entrambe le cose contemporaneamente. Cosa succede però nel caso in cui si vogliano combinare due o più documenti XML, ognuno de quali ha una propria DTD per ottenere un singolo documento? La risposta breve è che non è sempre possibile. Infatti, ammettendo che i documenti siano due, dato che la DTD di ogni documento molto probabilmente non è stata definita tenendo presenti le caratteristiche degli elementi della seconda DTD, esistono probabilità concrete che si verifichino delle collisioni tra i nomi delle due tipologie di documenti. In tal caso, sarebbe impossibile riuscire a differenziare gli elementi il cui nome è comune ad entrambe le DTD. I namespace XML sono stati ideati per aiutarci ad affrontare questo tipo di problemi. Un namespace XML non è altro che una collezione di nomi di elementi ed attributi identificata da un URI. Ogni nome di un determinato namespace XML viene quindi qualificato tramite l'uri che identifica il namespace stesso. In questo modo namespace XML differenti possono contenere nomi in comune senza che questo causi confusione, in quanto ogni singolo nome viene qualificato, tramite l'uri univoco del namespace che lo contiene. Un esempio di notazione a cui si è appena fatto cenno è la seguente: <soap:envelope xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:xsd="http://www.w3.org/2001/xmlschema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> In questo modo viene effettuata una dichiarazione di namespace utilizzando un nome di attributo speciale e riservato, xmlns, all'interno della dichiarazione di un elemento; in questo esempio il namespace viene applicato all'elemento <Envelope>. Il nome xsi separato da xmlns tramite un carattere : rappresenta il prefisso di namespace mentre il suo valore, specifica l'uri associato al namespace. Il solo scopo dell'uri che identifica il namespace consiste nell'assicurare che i nomi all'interno del namespace siano unici, indipendentemente dal fatto che l'uri esista oppure no. Come si nota dall'esempio proposto, è possibile aggiungere un numero qualsiasi di dichiarazioni di namespace all'interno di un elemento Lavorare con i documenti XML Nei paragrafi precedenti è stato introdotta la nozione di XML processor come modulo utilizzato da un'applicazione per leggere documenti XML. Un XML processor si occupa di effettuare il parsing del contenuto di un documento e di mettere a disposizione dell'applicazione gli elementi ed i relativi attributi: per questa ragione, l'xml processor viene spesso chiamato parser XML. Questi è quindi un modulo di programma che si occupa di suddividere il testo scritto in un determinato linguaggio nei suo componenti base, quindi da un punto di vista meramente implementativo un'applicazione accede al contenuto di un documento sfruttando le API messe a disposizione da un parser XML, ed il parser si occupa di svolgere tutte le operazioni necessarie per individuare ed interpretare le informazioni che compongono il documento stesso. Il linguaggio di programmazione Java supporta due API complementari per l'elaborazione di un 16/99

17 documento XML: SAX, acronimo di Simple API for XML; DOM, acronimo di Document Object Model for XML Elaborazione tramite SAX Per la lettura di un documento XML, SAX utilizza un procedimento basato sugli eventi che implementato tramite il meccanismo del callback, ovvero man mano che il parser legge un documento, ogni evento di parsing come, per esempio, il riconoscimento del tag di inizio o di fine di un elemento determina un richiamo ad un particolare metodo associato a tale evento. Questo metodo viene spesso chiamato handler, oppure gestore dell'evento. Il compito del programmatore consiste nell'implementare gli handler in modo da rispondere in maniera appropriata a ogni evento, e quindi reagire al contenuto del documento in base alle esigenze dell'applicazione. Il modo in cui lavora SAX si traduce necessariamente nel fatto che l'applicazione viene a conoscenza del contenuto del documento un pezzo per volta, senza poter lavorare su una sua rappresentazione totale. Ciò significa che, nel caso in cui il programma abbia la necessità di avere a disposizione l'intero documento all'interno di una struttura che ne riproduca il contenuto, bisogna costruire e riempire personalmente tale struttura con le informazioni invocate dai metodi di callback. <?xml version="1.0" encoding="utf-16"?> > Inizio documento <CurrentWeather> > Inizio elemento : CurrentWeather <Visibility> > Inizio elemento : Visibility greater than 7 mile(s): > Carattere : greater than 7 mile(s) : 0 </Visibility> > Fine elemento : Visibility <SkyConditions> > Inizio elemento : SkyConditions mostly clear > Carattere : mostly clear </SkyConditions> > Fine elemento : SkyConditions <Temperature> > Inizio elemento : Temperature 69 F (21 C) > Carattere : 69 F (21 C) </Temperature> > Fine elemento : Temperature </CurrentWeather> > Fine elemento : CurrentWeather Illustrazione 2.5: Elaborazione SAX di un documento XML Naturalmente, il lato positivo di questo approccio a eventi consiste nel fatto che non è obbligatorio mantenere l'intero documento in memoria. Bisogna evidenziare il fatto che SAX, di per se stesso, non è un vero e proprio parser di documenti XML, ma rappresenta solo una definizione di pubblico dominio di un'interfaccia verso un parser XML, e tale perser è rappresentato da un programma esterno. Dal punto fi vista della programmazione in Java le interfacce coinvolte nel procedimento sono molteplici. L'interfaccia XMLReader definita nel package org.xml.sax specifica i metodi che il parser SAX richiama man mano che riconosce elementi, attributi e altri componenti del documento XML. Di conseguenza, per intercettare e interpretare il contenuto di un documento XML è necessario creare una classe che implementi tali metodi e risponda in maniera appropriata alle chiamate di callback Elaborazione tramite DOM DOM lavora in maniera del tutto differente rispetto a SAX. Infatti, a fronte del parsing di un 17/99

18 documento XML, il DOM assembla in memoria l'intero albero gerarchico degli elementi del documento stesso e lo restituisce all'applicazione sotto forma di un oggetto di tipo Document che lo incapsula completamente. Illustrazione 2.6: Elaborazione DOM di un documento XML Non appena l'oggetto Document viene messo a disposizione dell'applicazione, è possibile richiamare i metodi dell'oggetto per navigare attraverso gli elementi dell'albero gerarchico del documento, partendo dall'elemento root del documento stesso. Con DOM, l'intero documento è totalmente disponibile per essere consultato ed elaborato un numero imprecisato di volte, ed in qualsiasi modo risulti adeguato agli scopi dell'applicazione. Questo è sicuramente il vantaggio sostanziale rispetto all'approccio seguito da SAX. Il lato negativo della metodologia seguita dal DOM consiste nella quantità di memoria occupata dalla rappresentazione del documento (non c'è scelta), il documento viene letto e memorizzato completamente in memoria, indipendentemente dalle sue dimensioni, e per alcuni particolari documenti la quantità di memoria necessaria può risultare proibitiva. Dal punto di vista implementativo del progetto proposto è sono state utilizzate le API open source di JDOM, sviluppate da Brett McLaughlin e Jason Hunter. In tale tecnologia, un documento XML viene rappresentato come un'istanza della classe org.jdom.document la quale fornisce anche l'analogo delle interfacce DOM come classi Java ma si osservi che la gerarchia di classi JDOM non ha alcuna relazione diretta con DOM, ad esempio la classe Node di JDOM non implementa l'interfaccia Node di DOM. La prima caratteristica Java-oriented di JDOM che lo sviluppatore incontra è il poter creare gli oggetti direttamente col proprio costruttore, senza la necessità di utilizzare metodi factory. Per creare ad esempio un oggetto org.jdom.element che rappresenta un tag <Document> è quindi sufficiente scrivere Element e = new Element("Document"); Per quanto riguarda il parsing di documenti XML JDOM fornisce i builder, oggetti che costruiscono un documento a partire da diverse sorgenti dati come file, InputStream e InputSource. Sono definiti due tipi di builder, DOMBuilder e SAXBuilder. Come è evidente dal nome DOMBuilder carica un documento a partire da un oggetto org.w3c.dom.document mentre SAXBuilder sfrutta un parser SAX ed è quindi più performante. Le seguenti righe di codice mostra come usare un SAXBuilder per eseguire il parsing di un file istanziando un documento JDOM: SAXBuilder builder = new SAXBuilder(true); Document doc = builder.build(new File(args[0])); //... Le classi SAXBuilder e DOMBuilder hanno vari costruttori in overloading che permettono di specificare quale parser usare (il default è Xerces) e se eseguire o meno la validazione del documento (il default è false). 18/99

19 2.5 Il protocollo SOAP SOAP è l acronimo di Simple Object Access Protocol e nell intenzione dei suoi sviluppatori dovrebbe costituire un protocollo d accesso ad oggetti remoti, basato su XML e semplice da utilizzare. Tale protocollo è in effetti semplice, ed in certi sensi user friendly ovvero, lo sviluppatore può curiosare all interno dei messaggi scambiati tra i vari nodi, visto che la comunicazione è in XML e questo ne ha decretato un successo tale da promuovere SOAP a standard affermato. Come vedremo, la semplicità del protocollo lascia però aperte numerose questioni che invece sono risolte in tecnologie distribuite più mature, come CORBA ed RMI. SOAP definisce la struttura dei singoli messaggi che vengono scambiati tra i nodi, definendo una serie di tag XML specifici. Utilizzando come riferimento questi elementi, chi riceve il messaggio è in grado di conoscere informazioni importanti sul messaggio stesso; nella forma più semplice, la struttura di un messaggio SOAP consente di mettere ordine e trasmettere le informazioni in modo strutturato. Un esempio di messaggio SOAP è presente nel seguente listato: <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:xsd="http://www.w3.org/2001/xmlschema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:body> <GetWeather xmlns="http://www.webservicex.net"> <CityName>Roma</CityName> <CountryName>Italy</CountryName> </GetWeather> </soap:body> </soap:envelope> Listato Un semplice esempio di messaggio SOAP Il messaggio presentato appartiene ad una ipotetica applicazione che fornisce le previsioni meteorologiche online. Come si nota, vengono inviati sia il nome della Città che la rispettiva nazione di appartenenza. Le specifiche di SOAP contengono in realtà quattro diversi aspetti: 1. la definizione del messaggio vero e proprio ed i modelli di scambio; 2. la codifica SOAP, uno standard per strutturare le informazioni in XML, per certi versi un antesignano di XML-Schema (è stato mutuato da una sua versione beta); 3. regole per utilizzare SOAP su mediante un opportuno protocollo di trasporto (generalmente HTTP); 4. regole per utilizzare SOAP per eseguire chiamate remote a procedure (RPC) Il messaggio SOAP e modelli di scambio Un messaggio SOAP è contenuto da un elemento XML più esterno chiamato envelope (busta) che funge da raccoglitore di tutti gli altri elementi. Al suo interno può essere presente l elemento header (intestazione) che può contenere metainformazioni sul messaggio, come dati sull autenticazione, criteri di sicurezza o sulla transazione distribuita in corso. Si noti però che questi aspetti non sono 19/99

20 definiti dal protocollo SOAP ma devono essere implementati, seguendo altri standard interni od esterni all azienda. Oltre all intestazione, la busta contiene l elemento body che è il vero deputato a contenere le informazioni applicative che è necessario comunicare al ricevente. SOAP E n v e lo p e Header E n t r ie s [H e a d e r E le m e n t] Body E le m e n t [ F a u lt E le m e n t ] [A tta ch m e n t] Illustrazione 2.7: struttura di un messaggio SOAP I messaggi SOAP vengono scambiati tra i nodi fondamentalmente in modalità one-way (a senso unico), dove cioè un nodo invia e l altro riceve. Illustrazione 2.8: Modello di scambio one-way Con questa modalità è possibile costruire interazioni più complesse, come quella di tipo Request/Response, che prevede anche una risposta. 20/99

21 Illustrazione 2.9: Modello di scambio Request/Response Un singolo nodo è tenuto, alla ricezione di un messaggio SOAP, ad eseguire una serie di operazioni: identificare tutte le componenti di sua competenza; verificare che tutti gli elementi obbligatori tra quelli identificati al punto precedente siano supportati dall applicazione, ed elaborarli di conseguenza; nel caso qualcosa vada male, il nodo deve ritornare un messaggio di errore (chiamato Fault); eventualmente analizzare le parti non di competenza del nodo (questa elaborazione è opzionale); se il nodo attuale non è il destinatario finale del messaggio, inoltrarlo al nodo successivo. Come si nota, la sequenza di eventi prevede la possibilità di instaurare una catena di nodi all ascolto di messaggi SOAP allo scopo di eseguire elaborazioni successive, ad esempio per implementare filtri o cache. Illustrazione 2.10: Un esempio di catena di ascoltatori SOAP, con filtri e cache La busta contiene due informazioni che ne consentono l identificazione della versione e la specifica dell encoding. <SOAP-ENV:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> In particolare: il namespace di appartenenza. Gli elementi XML propri del messaggio SOAP appartengono ad un namespace, il cui URI definisce la versione di SOAP utilizzata. Per SOAP 1.1 il namespace è In caso il server riceva un messaggio la cui versione è diversa da quella attesa, viene generato un errore (di tipo VersionMismatch); <SOAP-ENV:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> attributo encodingstyle. Indica quale standard è stato utilizzato per codificare il contenuto del messaggio (si veda il paragrafo SOAP Encoding). <SOAP-ENV:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> Nel caso in cui volessimo applicare la codifica di SOAP 1.2 bisogna sostituire la precedente URI 21/99

22 con Utilizzo dell intestazione Il blocco header ha uno scopo specifico nei messaggi SOAP: fornire metainformazioni sul messaggio principale, dati cioè, non strettamente legati alle informazioni applicative, ma relativi a questioni architetturali, quali l autenticazione o le transazioni distribuite. <SOAP-ENV:Header> <t:authentication xmlns:t="some-uri" SOAP-ENV:mustUnderstand="1"> <t:user>max</t:user> </t:token>163gd63gd3</7:token> </t:transaction> </SOAP-ENV:Header> Listato un esempio di header All interno dell intestazione è possibile utilizzare due attributi: actor. Identifica il destinatario di questo elemento di intestazione. Per indicare che l'elemento è destinato al primo nodo a ricevere il messaggio, è possibile specificare la costante: mustunderstand. Se questo attributo vale 1, la relativa sezione deve per forza essere elaborata dal nodo (se questa è indirizzata al nodo attuale). Se il nodo non è in grado di elaborarla, è necessario sollevare un fault; <t:authentication xmlns:t="some-uri" SOAP-ENV:mustUnderstand="1"> Gestione degli Errori Abbiamo visto che il contenuto di un messaggio SOAP deve prevedere un elemento di tipo body che contiene il messaggio applicativo. Nel caso però l elaborazione produca degli errori, il corpo del messaggio dovrà essere costituito da un (solo) elemento Fault. Questo contiene tutte le informazioni in merito all anomalia che si è presentata. <SOAP-ENV:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>soap-env:server</faultcode> <faultstring>server Error</faultstring> <detail> <e:myfaultdetails xmlns:e="some-uri"> <message>my application didn't work </message> <errorcode>1001</errorcode> </e:myfaultdetails> </detail> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Listato un esempio di Fault SOAP Le componenti di un messaggio Fault sono molteplici: faultcode. Definisce il codice di errore che è avvenuto, identificato da una stringa che lo individua univocamente. Le specifiche SOAP definiscono alcuni errori che si possono verificare perché legati ai funzionamenti intrinseci del protocollo, ed altri prefissi standard, 22/99

23 come Client e Server, che consentono di individuare se il problema è relativo alla richiesta del client od alla elaborazione del server; <faultcode>soap-env:server</faultcode> faultstring. Contiene sostanzialmente una descrizione dell errore leggibile dall essere umano; <faultstring>server Error</faultstring> faultactor. Definisce quale nodo del percorso intrapreso dal messaggio, ha generato questo errore; detail. Questo elemento può contenere un messaggio applicativo variabile, che può descrivere nel dettaglio il problema occorso. Nel listato sottostante è mostrato un blocco applicativo specifico, mentre spesso si inserisce uno stack trace della chiamata Java, all interno di un elemento CDATA. <detail> <e:myfaultdetails xmlns:e="some-uri"> <message>my application didn't work </message> <errorcode> 1001</errorcode> </e:myfaultdetails> </detail> SOAP su HTTP Come accennato, HTTP è un protocollo privilegiato per il trasporto di messaggio SOAP, forse anche perché le specifiche SOAP definiscono i meccanismi di veicolazione dei propri messaggi con questo protocollo che sono tra le altre cose anche abbastanza semplici. Per l invio di un messaggio, è necessario utilizzare il verbo HTTP POST, unitamente ad una nuova variabile di intestazione, SOAPAction, che definisce l intento della richiesta. Anche in virtù della libertà di utilizzo di questo elemento, spesso non viene utilizzato (infatti è definito come opzionale nelle specifiche), ed anzi, nella versione 1.2 di SOAP non è più presente. POST /globalweather.asmx HTTP/1.1 Host: Content-Type: text/xml; charset=utf-8 Content-Length: length SOAPAction: "http://www.webservicex.net/getweather" <?xml version="1.0" encoding="utf-8"?> <soap:envelope... Listato Una richiesta SOAP su HTTP Come si nota dal listato sottostante, SOAP su HTTP richiede che il content-type del messaggio sia text/xml. Content-Type: text/xml; charset=utf-8 La risposta segue poi le semantiche definite nei valori di stato di HTTP. Possiamo quindi avere: 200 se è andato tutto bene; 404 se il destinatario non è stato trovato; 500 se è avvenuto un errore interno (in questo caso il messaggio conterrà un elemento Fault). HTTP/ OK 23/99

24 Content-Type: text/xml; charset=utf-8 Content-Length: length <?xml version="1.0" encoding="utf-8"?> <soap:envelope... Listato una risposta SOAP su HTTP SOAP e RPC È giunto il momento, infine, di vedere come SOAP può essere utilizzato per rappresentare chiamate a procedure remote. Fino ad ora i singoli messaggi potevano sia ingaggiare procedure remote o semplicemente servire alla comunicazione di informazioni. La sezione delle specifiche di SOAP che ne definiscono il funzionamento come meccanismo di RPC, forniscono alcune regole uniformi per fare in modo che una chiamata RPC sia riconosciuta come tale. In particolare, la richiesta e la risposta sono modellate come strutture (struct) e codificate, preferibilmente, con l encoding SOAP. Il nome della struttura riprende quello del metodo da invocare, mentre la risposta ha lo stesso nome della richiesta, ma per convenzione contiene anche la parola Reponse. HTTP/ OK Content-Type: text/xml; charset=utf-8 Content-Length: length <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:xsd="http://www.w3.org/2001/xmlschema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:body> <GetWeatherResponse xmlns="http://www.webservicex.net"> <GetWeatherResult> <CurrentWeather> <Location> Roma / Urbe, Italy (LIRU) 41-57N E 24M </Location> <Time>Jun 23, :50 AM EDT / UTC</Time> <Wind> from the WSW (250 degrees) at 7 MPH (6 KT):0</Wind> <Visibility>greater than 7 mile(s):0</visibility> <SkyConditions> mostly clear</skyconditions > <Temperature> 91 F (33 C)</Temperature > <DewPoint> 62 F (17 C)</DewPoint > <RelativeHumidity> 38%</RelativeHumidity > <Pressure> in. Hg (1017 hpa)</pressure> <Status>Success</Status> </CurrentWeather> </GetWeatherResult> </GetWeatherResponse> </soap:body> </soap:envelope> 24/99

25 Listato Un esempio di RPC con SOAP Il metodo da invocare è identificato da un URI, che è specificato dal protocollo di trasporto utilizzato. Non esistono limitazioni alla forma dell URI utilizzato, tranne che questo sia valido. Altri elementi informativi non direttamente correlati alla chiamata del metodo, devono essere specificati come sottoelemento dell intestazione. Un esempio può essere l ID dell oggetto da chiamare, o quello della transazione: queste informazioni di contorno non sono pertinenti al corpo del messaggio ma all intestazione. Eventuali errori nell elaborazione della richiesta dovranno essere ritornati al chiamante come elementi Fault. Questa eventualità può succedere, oltre che per errori interni dell applicazione, anche per il fatto che alcuni parametri del metodo non risultano specificati nella richiesta SOAP Encoding Il corpo di un messaggio SOAP può definire un attributo chiamato encodingstyle che indica lo standard di codifica che è stato seguito nel popolare di informazioni il corpo del messaggio. Le specifiche SOAP 1.1 definiscono l encoding SOAP, una sorta di XML Schema in versione 0. La costante associata a questo encoding è: Non è però indispensabile utilizzare questo standard, è sufficiente utilizzarne uno che possa essere intellegibile sia da parte del client che del server. D altra parte, Microsoft stessa non ritiene che l encoding SOAP faccia parte del futuro dei servizi Web, ed anche il W3C ne ha reso opzionale la sua implementazione in SOAP 1.2 e ne ha eliminato il supporto da WSDL 1.2. Inoltre, e questo è un aspetto molto importante, la WS-I (Web Services Interoperability Organization), un consorzio di aziende che lavora per assicurare che le diverse implementazioni dei servizi Web possano comunicare tra di loro correttamente, non ne consente l utilizzo. Alla luce di queste notizie, non appare utile investire su un aspetto della tecnologia che in futuro non sarà più presente. Per completezza, riportiamo comunque un esempio di blocco dati codificato in SOAP encoding. <element name="age" type="int"/> <element name="height" type="float"/> <element name="displacement" type="negativeinteger"/> <element name="color"> <simpletype base="xsd:string"> <enumeration value="green"/> <enumeration value="blue"/> </simpletype> </element> <age>45</age> <height>5.9</height> <displacement>-450</displacement> <color>blue</color> Listato Un esempio di encoding SOAP 25/99

26 2.5.7 SOAP con Allegati Oltre alle specifiche SOAP 1.1, esiste anche un altro documento del W3C che definisce delle estensioni per poter veicolare assieme ad messaggio SOAP anche dei contenuti binari, come immagini o programmi eseguibili. Le specifiche in questione, definiscono l utilizzo di elementi MIME per poter specificare in un unico blocco testuale, più informazioni. MIME-Version: 1.0 Content-Type: Multipart/Related; boundary=mime_boundary; type=text/xml; Content-Description: Questa è una descrizione opzionale del messaggio. --MIME_boundary Content-Type: text/xml; charset=utf-8 Content-Transfer-Encoding: 8bit Content-ID: <?xml version='1.0'?> <SOAP-ENV:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body>.. <thesignedform </SOAP-ENV:Body> </SOAP-ENV:Envelope> --MIME_boundary Content-Type: image/tiff Content-Transfer-Encoding: binary Content-ID: TIFF image... --MIME_boundary-- Listato Un esempio di SOAP con allegati L esempio sopra riportato mostra un messaggio SOAP inviato insieme ad una immagine TIFF. Il formato ricalca la struttura del presente schema : 26/99

27 Illustrazione 2.11: La struttura di un messaggio SOAP con allegati Questa possibilità consente di associare ad un messaggio SOAP un elemento binario, come ad esempio un certificato di sicurezza o un blocco dati che risulta poco pratico o efficiente da codificare in XML. Una caratteristica interessante è la possibilità, da parte del messaggio SOAP, di puntare a URI assoluti (quindi all esterno del messaggio), ma anche interni, collegandosi dunque ad un altro allegato al messaggio. Si noti che il contenuto dell'allegato non deve per forza essere di tipo binario: è anche possibile allegare ulteriori documenti XML, quando le informazioni in esse contenute non risultino facilmente inseribili nel messaggio principale, o quando sia, dal punto di vista applicativo, preferibile mantenerle come documenti separati SOAP e Java Fino ad ora non si è parlato molto di Java, anche perché è giusto che l argomento relativo all implementazione di SOAP con Java sia affrontato con il dovuto spazio a disposizione. Come introduzione, è però possibile fare una carrellata sulle diverse strategie di approccio al problema. Queste possono essere: utilizzo a basso livello di XML. La piattaforma Java2 Standard Edition possiede il supporto nativo ai dati XML grazie alla tecnologia JAXP (Java API for XML Processing), che consente di accedere a dati XML tramite parser di tipo DOM e di tipo SAX. Inoltre, dispone della possibilità di eseguire trasformazioni XSLT. Grazie a questo supporto è possibile pensare di costruire messaggi SOAP (o di analizzarli). Questo approccio ha il vantaggio di non richiedere lo studio di una nuova API, ma dall altra espone direttamente a contatto con i 27/99

28 dettagli a basso livello del protocollo SOAP; utilizzo di API standard a basso livello (JAXM). JAXM è l implementazione Java del protocollo SOAP e consente di implementare codice server e client che utilizza questo standard. Anche JAXM è una tecnologia abbastanza a basso livello: alcune sue classi, come Envelope, Body, Header sono la diretta mappatura degli elementi presenti nei messaggi SOAP. Anche i singoli attributi che questi devono supportare, sono demandati allo sviluppatore che ne deve curare singolarmente ogni aspetto. Se da una parte questa soluzione presenta vantaggi rispetto al primo approccio, comunque è necessario molto codice per implementare complesse applicazioni distribuite basate su SOAP; utilizzo di API standard ad alto livello (JAXRPC). Fortunatamente, la piattaforma Java dispone anche di una tecnologia che consente di operare con SOAP ad un livello più alto. JAX-RPC (Java API for XML Remote Procedure Call) è una tecnologia che consente di generare, a fronte di una classe Java o di un file WSDL di definizione del servizio, tutta l infrastruttura necessaria ad implementare un client od un server. Ovviamente, il codice generato sarà compatibile con tutte le implementazioni di terze parti che saranno disponibili. JAX-RPC è stato inserito nella versione 1.4 di Java2 Enterprise Edition e dunque i container presenti negli application server si occuperanno di fornire l infrastruttura necessaria alle applicazioni JAX-RPC ad operare. Il vantaggio, con JAX-RPC, è che il codice SOAP viene generato dagli strumenti di sviluppo e non prodotto dal programmatore che però ha così meno controllo sui dettagli a basso livello, ma che vede ridursi i tempi di sviluppo; utilizzo di strumenti di terze parti. In ultima analisi, è possibile anche rivolgersi a strumenti ed API di terze parti, sia open-source, che commerciali. Un progetto interessante è ad esempio Apache Axis. Completa implementazione del protocollo SOAP, consente di realizzare servizi in modo molto semplice: è sufficiente creare una classe Java che implementi il servizio che si vuole erogare, cambiargli estensione da java a jws e posizionarla in una directory specifica sotto il web container. Si occuperà Axis di tramutare l interfaccia del servizio in un Web Service SOAP. 2.6 Il linguaggio WSDL WSDL è l acronimo di Web Services Description Language e può essere inteso come un linguaggio formale in formato XML utilizzato per la creazione di documenti per la descrizione di Web Service. Mediante WSDL può essere, infatti, descritta l'interfaccia pubblica di un Web Service ovvero creata una descrizione, basata su XML, di come interagire con un determinato servizio: un documento WSDL contiene infatti, relativamente al Web Service descritto, informazioni su: cosa può essere utilizzato (le operazioni messe a disposizione dal servizio); come utilizzarlo (il protocollo di comunicazione da utilizzare per accedere al servizio, il formato dei messaggi accettati in input e restituiti in output dal servizio ed i dati correlati) ovvero i vincoli (bindings in inglese) del servizio; dove utilizzare il servizio (cosiddetto endpoint del servizio che solitamente corrisponde all'indirizzo - in formato URI - che rende disponibile il Web Service) Le operazioni supportate dal Web Service ed i messaggi che è possibile scambiare con lo stesso sono descritti in maniera astratta e quindi collegati ad uno specifico protocollo di rete e ad uno specifico formato. Il WSDL è solitamente utilizzato in combinazione con SOAP e XML Schema per rendere disponibili Web Service su reti aziendali o su Internet: un programma client può, infatti, leggere da un registro UDDI il documento WSDL relativo ad un Web Service per determinare quali siano le funzioni messe a disposizione sul server e quindi utilizzare il protocollo SOAP per utilizzare una o più delle funzioni elencate dal WSDL. La versione 1.1 di WSDL non è stata adottata come standard dal World Wide Web Consortium 28/99

29 (W3C). Il 26 giugno 2007 la versione 2.0 è stata promossa a standard ufficiale (in forma di raccomandazione ) dal W3C. All'interno del documento esistono quattro elementi principali: <types> <message> <porttype> <binding> <service> W SDL D ocum ent [Typ es] {M essages} [ O p e r a t io n s ] { P o rt T y p e s} { B in d in g s } [P o rts] { S e r v ic e s } Illustrazione 2.12: Struttura di un documento WSDL1.1 Questi elementi vengono organizzati nel modo seguente (vedremo più avanti il loro contenuto): <definitions> <types> <!-- definizione dei tipi di dato utilizzati... --> </types> <message> <!-- definizione di uno dei messaggi impiegati dal web service per comunicare con l'applicazione client --> </message> <!-- naturalmente documento --> può esistere più di un elemento <porttype> <!-- definisce una "porta" e le operazioni che possono essere eseguite dal web service. Definisce inoltre i messaggi coinvolti nelle operazioni elencate --> 29/99 message all'interno del

30 </porttype> <binding> <!-- definisce il formato del messaggio ed i dettagli di protocollo per ogni porta --> </binding> <service> <!-- consente ad un client di determinare se un servizio specifico supporta tutte le operazioni che gli vengono richieste --> </service> </definitions> Listato Struttura di un documento WSDL1.1 Nei paragrafi che seguiranno prenderemo in analisi il file WSDL del Web Service Global Weather fornito da WebserviceX.net13, utilizzato all'interno di questo progetto L'elemento Type Abbiamo detto che all'interno del tag <types> bisogna definire i tipi che utilizzeremo nel documento, tale operazione risulta particolarmente facile per chi ha un minimo di conoscenza di XML Schema. Tutto quello che dobbiamo fare è inserire uno schema adatto ai nostri propositi. Supponendo di voler creare un operazione in grado di ricevere in input due stringhe, rappresentanti ad esempio la nazione e la città e di restituire le corrispettive previsioni meteo espresse ovviamente anch'esse in stringhe, possiamo fare come segue: All'interno di definitions impostiamo i namespace che ci servono, definendo inoltre wsdl come namespace base per gli elementi di questo documento. <wsdl:definitions xmlns:xs="http://www.w3.org/2001/xmlschema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns="http://schemas.xmlsoap.org/wsdl/" targetnamespace="urn:com.dominio.service.temperatureconverter"> <wsdl:definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:s="http://www.w3.org/2001/xmlschema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://www.webservicex.net" xmlns:tm="http://microsoft.com/wsdl/mime/textmatching/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetnamespace="http://www.webservicex.net" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> Listato Defnizione del tag defnitions Dato il nostro Web Service Global Weather utilizza solo strutturati, per il metodo GetWeather e la relativa risposta sono stati definiti i seguenti tipi: <wsdl:types> <s:schema elementformdefault="qualified" /99

31 targetnamespace="http://www.webservicex.net"> <s:element name="getweather"> <s:complextype> <s:sequence> <s:element minoccurs="0" maxoccurs="1 " name="cityname" type="s:string" /> <s:element minoccurs="0" maxoccurs="1" name="countryname" type="s:string" /> </s:sequence> </s:complextype> </s:element> <s:element name="getweatherresponse"> <s:complextype> <s:sequence> <s:element minoccurs="0" maxoccurs="1" name="getweatherresult" type="s:string" /> </s:sequence> </s:complextype> </s:element> ::::: <!-- continua descrizione dei tipi previsti per il metodo GetCitiesByCountry --> ::::: </s:schema> </wsdl:types> Listato Stralcio del tag Type del fle WDSL del Web Service Global Weather L'elemento Message Continuando sempre la nostra analisi sul metodo il metodo GetWeather, per inviare la coppia (CountryName, CityName) e ricevere le corrispettive previsioni meteorologiche, implica invocare due messaggi. Nella fattispecie, attraverso il primo dei due (la richiesta dell'applicazione) sarà inviata al Web Service la Città e la Nazione mentre con l'altro messaggio il Web Service invierà la risposta. Vediamo allora con un esempio questi due messaggi implementati:... <wsdl:message name="getweathersoapin"> <wsdl:part name="parameters" element="tns:getweather" /> </wsdl:message>... <wsdl:message name="getweathersoapout"> <wsdl:part name="parameters" element="tns:getweatherresponse" /> </wsdl:message> 31/99

32 ... Listato Defnizione dei blocchi Message Così facendo sono stati definiti due messaggi ad ognuno dei quali è stato dato un nome che utilizzeremo più avanti. Invece ogni parte (<part>) all'interno di un messaggio descrive da che cosa è composto ed ha a sua volta un nome che l'applicazione client userà per indicare i parametri che passa o riceve L'elemento PortType Questo elemento è senza dubbio il più importante all'interno di un documento WSDL infatti ha il compito di definire un Web Service, le operazioni che può effettuare ed i messaggi che sono coinvolti in questo processo. È importante anche sottolineare il valore astratto del <porttype>. Possiamo infatti compararlo con una libreria di funzioni del tutto simile a quella che troviamo nei principali linguaggi di programmazione. Questo risulta ulteriormente chiaro se ripetiamo ancora una volta che lo scopo di questo elemento è descrivere le operazioni (metodi) ed i messaggi che utilizzano (quindi il tipo degli argomenti passati e dei dati che ritornano). Ogni operazione definita all'interno del <porttype> può essere di quattro tipi: One-way (monodirezionale): un messaggio dal client al servizio; Illustrazione 2.13: Operazione One-Way Notification (notifica): il contrario dell'operazione one-way, ossia un messaggio dal servizio al client; Illustrazione 2.14: Operazione Notification Request-Response (richiesta-risposta): un messaggio da parte del client ed una risposta proveniente dal servizio; Illustrazione 2.15: Operazione RequestResponse Solicit-Response (sollecito-risposta): il contrario dell'operazione di request-response. In questo caso, il messaggio originale è trasmesso dal servizio ed è il client che risponde. 32/99

33 Illustrazione 2.16: Operazione SolicitResponse Proseguendo con l'esempio del metodo GetWeather è giunto il momento di analizzare anche l'elemento porttype. <wsdl:porttype name="globalweathersoap"> <wsdl:operation name="getweather"> <documentation xmlns="http://schemas.xmlsoap.org/wsdl/"> Get weather report for all major cities around the world. </documentation> <wsdl:input message="tns:getweathersoapin" /> <wsdl:output message="tns:getweathersoapout" /> </wsdl:operation> ::: </wsdl:porttype> Listato Defnizione di un nuovo blocco PortType Come potete notare definire il <porttype> è piuttosto semplice. È sufficiente infatti darli un nome ed inserire delle operazioni. Ogni operazione può essere composta da un messaggio di input, output oppure entrambi. Operazioni di solicit-response e request-response possono includere anche un terzo elemento (opzionale) chiamato fault che specifichi un messaggio con un formato valido per descrivere tutti gli errori che possono avvenire durante l'operazione. <fault message= faultmessage /> L'elemento Binding Una volta definito il il porttype bisogna che questi sia collegato con il protocollo SOAP tramite l'elemento <binding>. All'interno di questo paragrafo vedremo solamente un binding SOAP di tipo HTTP document. <wsdl:binding name="globalweathersoap" type="tns:globalweathersoap"> <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" /> <wsdl:operation name="getweather"> <soap:operation soapaction="http://www.webservicex.net/getweather" style="document" /> <wsdl:input> <soap:body use="literal" /> </wsdl:input> <wsdl:output> 33/99

34 <soap:body use="literal" /> </wsdl:output> </wsdl:operation> ::: </wsdl:binding> Listato Defnizione di un blocco Binding relativo al metodo GlobalWeatherSoap Come vediamo nell'esempio esistono due elementi binding, il primo appartenente al namespace di WSDL <wsdl:binding name="globalweathersoap" type="tns:globalweathersoap"> ed il secondo appartenente a SOAP. <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" /> Ovviamente sono due elementi diversi. Il primo ha due attributi, uno indica il nome dell'elemento (inserito a piacere) <wsdl:binding name="globalweathersoap" type="tns:globalweathersoap"> e l'altro il tipo del binding cioè il nome del nostro <porttype>. <wsdl:binding name="globalweathersoap" type="tns:globalweathersoap"> Una volta collegato il porttype al binding possiamo proseguire con il secondo elemento di questo tipo, quello appartenente a SOAP. Anche questo elemento ha due attributi: uno stile che può essere inpostato a rpc o document <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" /> ed un attributo transport. <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" /> In questo caso abbiamo usato document come style poiché riceveremo una risposta sotto forma di documento. L'attributo transport indica il protocollo da utilizzare con SOAP per comunicare e come possiamo leggere nell'uri abbiamo scelto HTTP. Giunti a questo punto, dopo aver definito i due elementi binding possiamo passare alla parte più interessante: definire i dettagli per le operazioni. Con il primo tag operation, quello più esterno, richiamiamo le operazioni che abbiamo già definito nell'elemento <porttype> <wsdl:operation name="getweather"> :::: </wsdl:operation> e per ognuna di queste definiamo il valore soapaction e confermiamo lo stile attraverso soap:operation. <soap:operation soapaction="http://www.webservicex.net/getweather" style="document" /> Come valore di soapaction abbiamo inserito un URI che nel mezzo ha una servlet. Questo serve 34/99

35 per sottolineare che l'attributo soapaction è molto importante (oltre che indispensabile) poiché ci servirà come descrizione dell'azione richiesta per il Web Service. All'interno del tag operation, dopo aver impostato l'elemento <soap:operation> bisogna elencare come saranno comunicati messaggi. Per farlo, ad ogni messaggio previsto dall'operazione che stiamo descrivendo dopo aver specificato il tipo con gli appositi tag (input, output o fault). <wsdl:input> <soap:body use="literal" /> </wsdl:input> <wsdl:output> <soap:body use="literal" /> </wsdl:output> <wsdlsoap:body> specifica come le parti del messaggio appariranno all'interno dell'elemento body di SOAP ed imposta la codifica da utilizzare se si è deciso di utilizzarla. Se non si desidera la codifica si può impostare l'attributo use con valore literal L'elemento Service service è il primo elemento che i vostri utenti vedono quando ricevono il documento WSDL. È stato progettato per riunire tutte le porte in relazione tra loro; in altri termini, l'elemento service consente ad un utente di determinare se un servizio specifico supporta tutte le operazioni che gli vengono richieste. Esiste, comunque, una regola in merito alla combinazione delle porte nei servizi: queste ultime non possono comunicare tra loro ossia non si possono concatenare in modo che l'output di una porta costituisca l'input di un'altra. <wsdl:service name="globalweather"> <wsdl:port name="globalweathersoap" binding="tns:globalweathersoap"> <soap:address location="http://www.webservicex.net/globalweather.asmx" /> </wsdl:port> ::: </wsdl:service> Listato Defnizione di un nuovo blocco Service Scegliamo il nome per il servizio <wsdl:service name="globalweather"> e colleghiamo una porta al al binding; <wsdl:port name="globalweathersoap" binding="tns:globalweathersoap"> per questa porta definiamo un punto di comunicazione con l'attributo location. <soap:address location="http://www.webservicex.net/globalweather.asmx" /> Finalmente abbiamo incontrato e realizzato tutte le parti di un documento WSDL. Possiamo quindi vedere la versione integrale del nostro WSDL. <?xml version="1.0" encoding="utf-8"?> <wsdl:definitions 35/99

36 xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:s="http://www.w3.org/2001/xmlschema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://www.webservicex.net" xmlns:tm="http://microsoft.com/wsdl/mime/textmatching/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetnamespace="http://www.webservicex.net" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> <wsdl:types> <s:schema elementformdefault="qualified" targetnamespace="http://www.webservicex.net"> <s:element name="getweather"> <s:complextype> <s:sequence> <s:element minoccurs="0" maxoccurs="1" name="cityname" type="s:string" /> <s:element minoccurs="0" maxoccurs="1" name="countryname" type="s:string" /> </s:sequence> </s:complextype> </s:element> <s:element name="getweatherresponse"> <s:complextype> <s:sequence> <s:element minoccurs="0" maxoccurs="1" name="getweatherresult" type="s:string" /> </s:sequence> </s:complextype> </s:element> <s:element name="getcitiesbycountry"> <s:complextype> <s:sequence> <s:element minoccurs="0" maxoccurs="1" name="countryname" type="s:string" /> </s:sequence> </s:complextype> </s:element> <s:element name="getcitiesbycountryresponse"> <s:complextype> <s:sequence> <s:element minoccurs="0" maxoccurs="1" name="getcitiesbycountryresult" 36/99

37 type="s:string" /> </s:sequence> </s:complextype> </s:element> <s:element name="string" nillable="true" type="s:string" /> </s:schema> </wsdl:types> <wsdl:message name="getweathersoapin"> <wsdl:part name="parameters" element="tns:getweather" /> </wsdl:message> <wsdl:message name="getweathersoapout"> <wsdl:part name="parameters" element="tns:getweatherresponse" /> </wsdl:message> <wsdl:message name="getcitiesbycountrysoapin"> <wsdl:part name="parameters" element="tns:getcitiesbycountry" /> </wsdl:message> <wsdl:message name="getcitiesbycountrysoapout"> <wsdl:part name="parameters" element="tns:getcitiesbycountryresponse" /> </wsdl:message> <wsdl:message name="getweatherhttpgetin"> <wsdl:part name="cityname" type="s:string" /> <wsdl:part name="countryname" type="s:string" /> </wsdl:message> <wsdl:message name="getweatherhttpgetout"> <wsdl:part name="body" element="tns:string" /> </wsdl:message> <wsdl:message name="getcitiesbycountryhttpgetin"> <wsdl:part name="countryname" type="s:string" /> </wsdl:message> <wsdl:message name="getcitiesbycountryhttpgetout"> <wsdl:part name="body" element="tns:string" /> </wsdl:message> <wsdl:message name="getweatherhttppostin"> <wsdl:part name="cityname" type="s:string" /> <wsdl:part name="countryname" type="s:string" /> </wsdl:message> <wsdl:message name="getweatherhttppostout"> <wsdl:part name="body" element="tns:string" /> 37/99

38 </wsdl:message> <wsdl:message name="getcitiesbycountryhttppostin"> <wsdl:part name="countryname" type="s:string" /> </wsdl:message> <wsdl:message name="getcitiesbycountryhttppostout"> <wsdl:part name="body" element="tns:string" /> </wsdl:message> <wsdl:porttype name="globalweathersoap"> <wsdl:operation name="getweather"> <documentation xmlns="http://schemas.xmlsoap.org/wsdl/"> Get weather report for all major cities around the world. </documentation> <wsdl:input message="tns:getweathersoapin" /> <wsdl:output message="tns:getweathersoapout" /> </wsdl:operation> <wsdl:operation name="getcitiesbycountry"> <documentation xmlns="http://schemas.xmlsoap.org/wsdl/"> Get all major cities by country name (full / part). </documentation> <wsdl:input message="tns:getcitiesbycountrysoapin" /> <wsdl:output message="tns:getcitiesbycountrysoapout" /> </wsdl:operation> </wsdl:porttype> <wsdl:porttype name="globalweatherhttpget"> <wsdl:operation name="getweather"> <documentation xmlns="http://schemas.xmlsoap.org/wsdl/"> Get weather report for all major cities around the world. </documentation> <wsdl:input message="tns:getweatherhttpgetin" /> <wsdl:output message="tns:getweatherhttpgetout" /> </wsdl:operation> <wsdl:operation name="getcitiesbycountry"> <documentation xmlns="http://schemas.xmlsoap.org/wsdl/"> Get all major cities by country name (full / part). </documentation> <wsdl:input message="tns:getcitiesbycountryhttpgetin" /> <wsdl:output message="tns:getcitiesbycountryhttpgetout" /> </wsdl:operation> </wsdl:porttype> 38/99

39 <wsdl:porttype name="globalweatherhttppost"> <wsdl:operation name="getweather"> <documentation xmlns="http://schemas.xmlsoap.org/wsdl/"> Get weather report for all major cities around the world. </documentation> <wsdl:input message="tns:getweatherhttppostin" /> <wsdl:output message="tns:getweatherhttppostout" /> </wsdl:operation> <wsdl:operation name="getcitiesbycountry"> <documentation xmlns="http://schemas.xmlsoap.org/wsdl/"> Get all major cities by country name (full / part). </documentation> <wsdl:input message="tns:getcitiesbycountryhttppostin" /> <wsdl:output message="tns:getcitiesbycountryhttppostout" /> </wsdl:operation> </wsdl:porttype> <wsdl:binding name="globalweathersoap" type="tns:globalweathersoap"> <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" /> <wsdl:operation name="getweather"> <soap:operation soapaction="http://www.webservicex.net/getweather" style="document" /> <wsdl:input> <soap:body use="literal" /> </wsdl:input> <wsdl:output> <soap:body use="literal" /> </wsdl:output> </wsdl:operation> <wsdl:operation name="getcitiesbycountry"> <soap:operation soapaction="http://www.webservicex.net/getcitiesbycountry" style="document" /> <wsdl:input> <soap:body use="literal" /> </wsdl:input> <wsdl:output> <soap:body use="literal" /> </wsdl:output> </wsdl:operation> 39/99

40 </wsdl:binding> <wsdl:binding name="globalweatherhttpget" type="tns:globalweatherhttpget"> <http:binding verb="get" /> <wsdl:operation name="getweather"> <http:operation location="/getweather" /> <wsdl:input> <http:urlencoded /> </wsdl:input> <wsdl:output> <mime:mimexml part="body" /> </wsdl:output> </wsdl:operation> <wsdl:operation name="getcitiesbycountry"> <http:operation location="/getcitiesbycountry" /> <wsdl:input> <http:urlencoded /> </wsdl:input> <wsdl:output> <mime:mimexml part="body" /> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:binding name="globalweatherhttppost" type="tns:globalweatherhttppost"> <http:binding verb="post" /> <wsdl:operation name="getweather"> <http:operation location="/getweather" /> <wsdl:input> <mime:content type="application/x-www-form-urlencoded" /> </wsdl:input> <wsdl:output> <mime:mimexml part="body" /> </wsdl:output> </wsdl:operation> <wsdl:operation name="getcitiesbycountry"> <http:operation location="/getcitiesbycountry" /> <wsdl:input> <mime:content type="application/x-www-form-urlencoded" /> 40/99

41 </wsdl:input> <wsdl:output> <mime:mimexml part="body" /> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="globalweather"> <wsdl:port name="globalweathersoap" binding="tns:globalweathersoap"> <soap:address location="http://www.webservicex.net/globalweather.asmx" /> </wsdl:port> <wsdl:port name="globalweatherhttpget" binding="tns:globalweatherhttpget"> <http:address location="http://www.webservicex.net/globalweather.asmx" /> </wsdl:port> <wsdl:port name="globalweatherhttppost" binding="tns:globalweatherhttppost"> <http:address location="http://www.webservicex.net/globalweather.asmx" /> </wsdl:port> </wsdl:service> </wsdl:definitions> Listato Listato completo del WSDL del Web Service Global Weather 2.7 Il protocollo UDDI UDDI è l'acronimo di Universal Description, Discovery and Integration ed è un servizio di directory che consente agli utenti di localizzare i servizi Web. In sostanza, UDDI è un registry (ovvero una base dati ordinata ed indicizzata), basato su XML ed indipendente dalla piattaforma hardware, che permette alle aziende la pubblicazione dei propri dati e dei servizi Web offerti su Internet. UDDI, è un'iniziativa open sviluppata tra il 1999 ed il 2000 e sponsorizzata dall'organization for the Advancement of Structured Information Standards (consorzio internazionale per lo sviluppo e l'adozione di standard nel campo dell'e-business e dei Web Services spesso indicato anche come OASIS), permette quindi la scoperta e l'interrogazione dei servizi offerti sul web, delle aziende che li offrono e della maniera per usufruirne Il contesto architetturale di UDDI Ci sono due modi per considerare il contesto architetturale di un Web Service. Il primo è esaminare i ruoli individuali; il secondo è esaminare la pila dei protocolli in cui si inserisce UDDI I ruoli in UDDI Ci sono due ruoli principali all interno dell architettura UDDI come è possibile evincere dall'illustrazione. 41/99

42 R e g is tr o U D D I P u b lis h e r U te n te Illustrazione 2.17: I ruoli in UDDI Publisher: è il fornitore del servizio. Il Publisher implementa il servizio e lo rende disponibile pubblicandolo sul registro UDDI. Utente: è il fruitore del servizio. L utente consulta l elenco, localizza il Web Service e invoca il servizio richiesto che viene eseguito dal Publisher Il registro UDDI Il registro UDDI è supportato da una rete mondiale di nodi, collegati tra di loro in una sorta di federazione, in modo similare alla tecnologia DNS. Quando un client sottopone una informazione al registro, questo la propaga agli altri nodi. In questo modo si attua la ridondanza dei dati, fornendo una certa affidabilità. Il ruolo del singolo nodo rimane comunque fondamentale, poiché, nel momento in cui un client gli sottopone dei dati, questo ne diviene il proprietario, e sarà in futuro solo questo nodo a poter operare importanti operazioni sui dati, quali la loro eliminazione Rappresentazione delle informazioni in UDDI Ricapitolando UDDI tratta un insieme di funzioni che permettono di: Registrare aziende, servizi e informazioni per raggiungere i servizi stessi. Modificare o cancellare le registrazioni. Ricercare il database delle registrazioni. Operativamente un azienda che vuole rendere disponibile un Web Service dovrà: Registrarsi come azienda in quanto tale. Registrare il servizio offerto da un punto di vista descrittivo. Registrare le informazioni necessarie ad invocare il servizio, come per esempio la URL presso cui è esposto. Concettualmente, queste informazioni che devono essere fornite, coerentemente con le specifiche previste da UDDI, possono essere divise in tre blocchi fondamentali: White Pages, Yellow Pages e Green Pages. 42/99

43 Illustrazione 2.18: Informazioni presenti in UDDI Con le White Pages (pagine bianche) possiamo trovare informazioni come gli indirizzi di una azienda o contatti ad essa relativi. Nelle Yellow Pages (pagine gialle) le aziende ed i loro servizi vengono catalogati sotto differenti categorie e classificazioni. Infine vi sono le Green Pages (pagine verdi), dove sono contenute informazioni tecniche relative ai servizi, grazie alle quali questi ultimi possono essere invocati. Questa è la suddivisione dell informazione dentro UDDI a livello concettuale ma vediamo come è realmente strutturato un UDDI Registry Struttura di UDDI Illustrazione 2.19: Struttura principale di un registro UDDI. Le parti principali di un registro UDDI, sono quattro, in ognuna delle quali è memorizzato un certo tipo di informazione: businessentity: informazioni relative alle compagnie o aziende che hanno pubblicato uno o più Web Service (White Pages). businessservice: informazioni descrittive relative ad un particolare servizio (Yellow Pages). bindingtemplate: informazioni tecniche relative ad un Web Service, come ad esempio l entry point (Green Pages). tmodel: informazioni tecniche che descrivono una particolare tipologia di servizio, riportandone la specifica dell interfaccia (Green Pages). Una businessentity possiede informazioni come nome, indirizzo e contatti di una azienda che ha pubblicato dei Web Service. <element name = businessentity > <complextype> 43/99

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

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

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

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

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

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

Web Services Security

Web Services Security Web Services Security Introduzione ai Web Services Davide Marrone Sommario Cosa sono i web services Architettura dei web services XML-RPC SOAP (Simple Object Access Protocol) WSDL (Web Services Description

Dettagli

Gli XML Web Service. Prof. Mauro Giacomini. Complementi di Informatica Medica 2008/2009 1

Gli XML Web Service. Prof. Mauro Giacomini. Complementi di Informatica Medica 2008/2009 1 Gli XML Web Service Prof. Mauro Giacomini Medica 2008/2009 1 Definizioni i i i Componente.NET che risponde a richieste HTTP formattate tramite la sintassi SOAP. Gestori HTTP che intercettano richieste

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

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

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

Introduzione a XML: Document Type Definition; parser XML; XML-schema; extensible Stylesheet Language. a.a. 2004/05 Tecnologie Web 1

Introduzione a XML: Document Type Definition; parser XML; XML-schema; extensible Stylesheet Language. a.a. 2004/05 Tecnologie Web 1 Introduzione a XML: Document Type Definition; parser XML; XML-schema; extensible Stylesheet Language a.a. 2004/05 Tecnologie Web 1 XML - I XML (exstensible Markup Language): XML è un formato standard,

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

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

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

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

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

Corso di Applicazioni Telematiche

Corso di Applicazioni Telematiche Service Oriented Architectures e Web Services Corso di Applicazioni Telematiche A.A. 20010-11 Prof. Simon Pietro Romano Università degli Studi di Napoli Federico II Facoltà di Ingegneria Cos è un Web Service?

Dettagli

Sistema integrato dei portali RAS: specifiche di integrazione

Sistema integrato dei portali RAS: specifiche di integrazione Sistema integrato dei portali RAS: specifiche di integrazione Linee guida tecniche per l'integrazione con il presentation layer del CMS RAS Data: File: Allegato 3 - Specifiche di integrazione SIP-RAS.odt

Dettagli

Service Oriented Architectures (SOA)

Service Oriented Architectures (SOA) Facoltà di Ingegneria dell Informazione Laurea Specialistica in Ingegneria Informatica Facoltà di Ingegneria dei Sistemi Laurea Magistrale in Ingegneria Biomedica Dipartimento di Elettronica e Informazione

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

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

Architetture orientate ai servizi

Architetture orientate ai servizi Architetture orientate ai servizi 1 Web Service Nuovo paradigma di sistema informativo basato su componenti software distribuiti I Web Service sono applicazioni indipendenti, modulari, autodescrittive,

Dettagli

Software per la gestione di musei di arte contemporanea1

Software per la gestione di musei di arte contemporanea1 Software per la gestione di musei di arte contemporanea1 Identificativo del progetto: CA Nome documento: System Design(SD) Identificativo del documento: 6 CA_SD_E1_R1 Data del documento: 21/05/2012 Prima

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

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

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

Reti basate sulla stack di protocolli TCP/IP

Reti basate sulla stack di protocolli TCP/IP Reti basate sulla stack di protocolli TCP/IP Classe V sez. E ITC Pacioli Catanzaro lido 1 Stack TCP/IP Modello TCP/IP e modello OSI Il livello internet corrisponde al livello rete del modello OSI, il suo

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

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

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

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

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

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

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

Un introduzione ai Web service

Un introduzione ai Web service Un introduzione ai Web service Valeria Cardellini Università di Roma Tor Vergata Definizione di Web service Definizione fornita del W3C http://www.w3.org/tr/ws-arch/ A Web service is a software system

Dettagli

Livello cinque (Livello application)

Livello cinque (Livello application) Cap. VII Livello Application pag. 1 Livello cinque (Livello application) 7. Generalità: In questo livello viene effettivamente svolto il lavoro utile per l'utente, contiene al suo interno diverse tipologie

Dettagli

LABORATORIO DI INFORMATICA

LABORATORIO DI INFORMATICA Università degli Studi di Ferrara Facoltà di Lettere e Filosofia Corso di Laurea in «Scienze dell educazione» AA 2011-2012 LABORATORIO DI INFORMATICA Prof. Giorgio Poletti giorgio.poletti@unife.it La rete

Dettagli

Il Livello delle Applicazioni

Il Livello delle Applicazioni Il Livello delle Applicazioni Il livello Applicazione Nello stack protocollare TCP/IP il livello Applicazione corrisponde agli ultimi tre livelli dello stack OSI. Il livello Applicazione supporta le applicazioni

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

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

La domotica e l'informatica

La domotica e l'informatica Istituto di Scienza e Tecnologie dell'informazione A Faedo (ISTI) Laboratorio di domotica La domotica e l'informatica Dario Russo (dario.russo@isti.cnr.it) Cosa è l'informatica L'informatica è una scienza

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

Sistemi informatici in ambito radiologico

Sistemi informatici in ambito radiologico Sistemi informatici in ambito radiologico Dott. Ing. Andrea Badaloni A.A. 2015 2016 Reti di elaboratori, il modello a strati e i protocolli di comunicazione e di servizio Reti di elaboratori Definizioni

Dettagli

Capitolo 16 I servizi Internet

Capitolo 16 I servizi Internet Capitolo 16 I servizi Internet Storia di Internet Il protocollo TCP/IP Indirizzi IP Intranet e indirizzi privati Nomi di dominio World Wide Web Ipertesti URL e HTTP Motori di ricerca Posta elettronica

Dettagli

Università della Calabria

Università della Calabria 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

Dettagli

Architettura Connettore Alfresco Share

Architettura Connettore Alfresco Share Direzione Sistemi Informativi Portale e Orientamento Allegato n. 2 al Capitolato Tecnico Indice Architettura Connettore Alfresco Share 1. Architettura del Connettore... 3 1.1 Componente ESB... 4 1.2 COMPONENTE

Dettagli

Sviluppo di applicazioni web con il pattern Model-View-Controller. Gabriele Pellegrinetti

Sviluppo di applicazioni web con il pattern Model-View-Controller. Gabriele Pellegrinetti Sviluppo di applicazioni web con il pattern Model-View-Controller Gabriele Pellegrinetti 2 MVC: come funziona e quali sono vantaggi che derivano dal suo utilizzo? La grande diffusione della tecnologia

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

OpenSPCoop: un implementazione della Specifica di Cooperazione Applicativa per la Pubblica Amministrazione Italiana

OpenSPCoop: un implementazione della Specifica di Cooperazione Applicativa per la Pubblica Amministrazione Italiana UNIVERSITÀ DI PISA Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di Laurea Specialistica in Tecnologie Informatiche Tesi di Laurea Specialistica OpenSPCoop: un implementazione della Specifica

Dettagli

Informatica Documentale

Informatica Documentale Informatica Documentale Ivan Scagnetto (scagnett@dimi.uniud.it) Stanza 3, Nodo Sud Dipartimento di Matematica e Informatica Via delle Scienze, n. 206 33100 Udine Tel. 0432 558451 Ricevimento: giovedì,

Dettagli

a cura di Maria Finazzi

a cura di Maria Finazzi Esercitazioni di XML a cura di Maria Finazzi (11-19 gennaio 2007) e-mail: maria.finazzi@unipv.it pagine web: Il trattamento dell'informazione Testo a stampa: Come

Dettagli

Gestione XML della Porta di Dominio OpenSPCoop

Gestione XML della Porta di Dominio OpenSPCoop i Gestione XML della Porta di Dominio ii Copyright 2005-2011 Link.it srl iii Indice 1 Introduzione 1 2 Hello World! 2 3 Configurazione XML della Porta di Dominio 5 3.1 Soggetto SPCoop...................................................

Dettagli

HTML e Linguaggi. Politecnico di Milano Facoltà del Design Bovisa. Prof. Gianpaolo Cugola Dipartimento di Elettronica e Informazione

HTML e Linguaggi. Politecnico di Milano Facoltà del Design Bovisa. Prof. Gianpaolo Cugola Dipartimento di Elettronica e Informazione HTML e Linguaggi Politecnico di Facoltà del Design Bovisa Prof. Gianpaolo Cugola Dipartimento di Elettronica e Informazione cugola@elet.polimi.it http://home.dei.polimi.it/cugola Indice Il linguaggio del

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

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

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

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

Reti di Calcolatori. Master "Bio Info" Reti e Basi di Dati Lezione 2

Reti di Calcolatori. Master Bio Info Reti e Basi di Dati Lezione 2 Reti di Calcolatori Sommario Software di rete TCP/IP Livello Applicazione Http Livello Trasporto (TCP) Livello Rete (IP, Routing, ICMP) Livello di Collegamento (Data-Link) I Protocolli di comunicazione

Dettagli

INDICE. Indice. Introduzione

INDICE. Indice. Introduzione V Indice Introduzione XIII Capitolo 1 La programmazione multithread 1 1.1 Cosa sono i thread 2 Utilizzare i thread per dare una possibilità ad altri task 9 Avvio ed esecuzione dei thread 10 Esecuzione

Dettagli

Tecnologie Web T Introduzione a XML

Tecnologie Web T Introduzione a XML Tecnologie Web T Introduzione a Home Page del corso: http://www-db.deis.unibo.it/courses/tw/ Versione elettronica: 2.01..pdf Versione elettronica: 2.01.-2p.pdf 1 Che cos è? : Extensible Markup Language:

Dettagli

Framework. Impianti Informatici. Web application - tecnologie

Framework. Impianti Informatici. Web application - tecnologie Framework Web application - tecnologie Web Application: tecnologie 2 Java-based (J2EE) Sviluppata inizialmente da Sun Cross-platform e open source Gestire direttamente le funzionalità dell applicazione

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

IBM Software Demos The Front-End to SOA

IBM Software Demos The Front-End to SOA Oggi, imprese piccole e grandi utilizzano software basato sull'architettura SOA (Service-Oriented Architecture), per promuovere l'innovazione, ottimizzare i processi aziendali e migliorare l'efficienza.

Dettagli

Definizione di Web service (2) Un introduzione ai Web service. Caratteristiche dei Web service. Valeria Cardellini Università di Roma Tor Vergata

Definizione di Web service (2) Un introduzione ai Web service. Caratteristiche dei Web service. Valeria Cardellini Università di Roma Tor Vergata Definizione di Web service Definizione fornita del W3C http://www.w3.org/tr/ws-arch/ Un introduzione ai Web service Valeria Cardellini Università di Roma Tor Vergata A Web service is a software system

Dettagli

Internet e Tecnologia Web

Internet e Tecnologia Web INTERNET E TECNOLOGIA WEB Corso WebGis per Master in Sistemi Informativi Territoriali AA 2005/2006 ISTI- CNR c.renso@isti.cnr.it Internet e Tecnologia Web...1 TCP/IP...2 Architettura Client-Server...6

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

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

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

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

Laboratorio Matematico Informatico 2

Laboratorio Matematico Informatico 2 Laboratorio Matematico Informatico 2 (Matematica specialistica) A.A. 2006/07 Pierluigi Amodio Dipartimento di Matematica Università di Bari Laboratorio Matematico Informatico 2 p. 1/1 Informazioni Orario

Dettagli

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY

PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Giampiero Allamprese 0000260193 PROGETTO DI UN MIDDLEWARE PER L ACCESSO REMOTO A UN REPOSITORY Reti di Calcolatori LS prof. Antonio Corradi A.A. 2007/2008 ABSTRACT L obiettivo di questo progetto è la realizzazione

Dettagli

Sistemi Operativi (modulo di Informatica II)

Sistemi Operativi (modulo di Informatica II) Sistemi Operativi (modulo di Informatica II) La comunicazione tra processi Patrizia Scandurra Università degli Studi di Bergamo a.a. 2008-09 Sommario Processi cooperanti La comunicazione tra processi Necessità

Dettagli

Architetture Web I Server Web e gli Standard della Comunicazione

Architetture Web I Server Web e gli Standard della Comunicazione Architetture Web I Server Web e gli Standard della Comunicazione Alessandro Martinelli alessandro.martinelli@unipv.it 27 Marzo 2012 Architetture Architetture Web Protocolli di Comunicazione Il Client Side

Dettagli

Introduzione a XML. Language

Introduzione a XML. Language Introduzione a XML 1 Che cos è XML? XML: Extensible Markup Language anguage: è un linguaggio che consente la rappresentazione di documenti e dati strutturati su supporto digitale è uno strumento potente

Dettagli

Registro SPICCA Architettura del Software

Registro SPICCA Architettura del Software Registro SPICCA Architettura del Software Versione 1.0 del 25/08/2009 Sommario 1 Introduzione... 4 1.1 Scopo... 4 1.2 Obiettivo... 4 1.3 Riferimenti... 4 1.4 Panoramica del documento... 4 2 Rappresentazione

Dettagli

Corso di Sistemi di Elaborazione delle informazioni

Corso di Sistemi di Elaborazione delle informazioni Corso di Sistemi di Elaborazione delle informazioni Reti di Calcolatori Claudio Marrocco Componenti delle reti Una qualunque forma di comunicazione avviene: a livello hardware tramite un mezzo fisico che

Dettagli

Definizione delle interfacce di colloquio fra le componenti

Definizione delle interfacce di colloquio fra le componenti Definizione delle interfacce di colloquio fra le componenti (integrazione documento) 1 DOCUMENTO:. 1.2 Emesso da: EMISSIONE VERIFICA APPROVAZIONE Nome firma Verificato da: Approvato da: Area ISIC LISTA

Dettagli

Table of Contents. Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano

Table of Contents. Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Table of Contents Definizione di Sistema Distribuito - 4 Obiettivi Principali di un S.D. - 7 Tipi di Sistemi

Dettagli

Capitolo 3. Il funzionamento delle reti

Capitolo 3. Il funzionamento delle reti Capitolo 3 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

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

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

PROGETTI di E-government Area Sanità

PROGETTI di E-government Area Sanità PROGETTI di E-government Area Sanità Regione del Veneto Fabio Perina 15 dicembre 2004 Medici Di Base Cup IL ROGETTO Distretti Farmacie Repository Reparti Laboratori Sistema Accessi Gestore Eventi Comuni

Dettagli

Corso Sviluppatore servizi per il Web (WCF) Lezione 01

Corso Sviluppatore servizi per il Web (WCF) Lezione 01 01 Introduzione Introduzione alla tecnologia WCF Premessa Il corso su WCF di cui state leggendo la prima lezione, vi guiderà alla scoperta di questa nuova tecnologia introdotta da Microsoft per venire

Dettagli

Sommario. Settimana - Gli elementi fondamentali... 1. Introduzione...xv. Giorno 1 - I linguaggi di markup...3

Sommario. Settimana - Gli elementi fondamentali... 1. Introduzione...xv. Giorno 1 - I linguaggi di markup...3 000B-XML-Somm.fm Page iii Wednesday, June 12, 2002 9:25 AM Sommario Introduzione...xv A chi si rivolge questo libro...xvi Convenzioni usate in questo libro...xvi Settimana - Gli elementi fondamentali...

Dettagli

CORBA ( Common Object Request Broker Architecture ) Le specifiche più conosciute sono UML e CORBA

CORBA ( Common Object Request Broker Architecture ) Le specifiche più conosciute sono UML e CORBA CORBA ( Common Object Request Broker Architecture ) consiste in un insieme di specifiche promosse e curate da OMG (Object Management Group). L OMG è un consorzio internazionale no-profit di industrie nel

Dettagli

Table of Contents. Definizione di Sistema Distribuito 15/03/2013

Table of Contents. Definizione di Sistema Distribuito 15/03/2013 Insegnamento: Sistemi Distribuiti - 6 cfu LM Ing. Informatica Docente: Prof. Marcello Castellano Table of Contents Definizione di Sistema Distribuito - 4-7 - 13 Definizioni e Principali Caratteristiche

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

SPECIFICHE TECNICHE INTEGRAZIONE SERVIZI MUDE

SPECIFICHE TECNICHE INTEGRAZIONE SERVIZI MUDE Pag. 1 di 11 VERIFICHE E APPROVAZIONI VERSIONE REDAZIONE CONTROLLO AUTORIZZAZIONE APPROVAZIONE EMISSIONE NOME DATA NOME DATA NOME DATA V01 Mauro Pavese 17/05/12 Mauro Pavese 29/11/2012 STATO DELLE VARIAZIONI

Dettagli

Sistemi Distribuiti. Informatica B. Informatica B

Sistemi Distribuiti. Informatica B. Informatica B Sistemi Distribuiti Introduzione Che cos è un sistema distribuito? Un sistema distribuito è una collezione di computer indipendenti che appare all utente come un solo sistema coerente Da notare: le macchine

Dettagli

Applicazioni e Architetture Internet. T. Catarci, M. Scannapieco, Corso di Basi di Dati, A.A. 2008/2009, Sapienza Università di Roma

Applicazioni e Architetture Internet. T. Catarci, M. Scannapieco, Corso di Basi di Dati, A.A. 2008/2009, Sapienza Università di Roma Applicazioni e Architetture Internet 1 Introduzione Introduzione alle architetture a tre livelli Formati di dati per il Web HTML, XML, DTD 2 Componenti dei sistemi dataintensive Tre tipi separati di funzionalità:

Dettagli

Introduzione a Service Oriented Architecture e Web Service

Introduzione a Service Oriented Architecture e Web Service Università degli Studi di Roma Tor Vergata Dipartimento di Ingegneria Civile e Ingegneria Informatica Introduzione a Service Oriented Architecture e Web Service Corso di Sistemi Distribuiti e Cloud Computing

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

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

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

Iniziativa Comunitaria Equal II Fase IT G2 CAM - 017 Futuro Remoto. Approfondimento INTERNET: IL FUNZIONAMENTO DELL INFRASTRUTTURA E DELLA RETE

Iniziativa Comunitaria Equal II Fase IT G2 CAM - 017 Futuro Remoto. Approfondimento INTERNET: IL FUNZIONAMENTO DELL INFRASTRUTTURA E DELLA RETE APPROFONDIMENTO ICT Iniziativa Comunitaria Equal II Fase IT G2 CAM - 017 Futuro Remoto Approfondimento INTERNET: IL FUNZIONAMENTO DELL INFRASTRUTTURA E DELLA RETE ORGANISMO BILATERALE PER LA FORMAZIONE

Dettagli

Applicazione: Piattaforma di Comunicazione Unificata

Applicazione: Piattaforma di Comunicazione Unificata Riusabilità del software - Catalogo delle applicazioni: Amministrativi/Contabile Applicazione: Piattaforma di Comunicazione Unificata Amministrazione: Regione Piemonte - Direzione Innovazione, Ricerca

Dettagli

Guida Utente della PddConsole. Guida Utente della PddConsole

Guida Utente della PddConsole. Guida Utente della PddConsole Guida Utente della PddConsole i Guida Utente della PddConsole Guida Utente della PddConsole ii Copyright 2005-2015 Link.it srl Guida Utente della PddConsole iii Indice 1 Introduzione 1 2 I protocolli di

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