Istituto Tecnico Industriale G. Marconi - Rovereto (TN) Informatica WEB SERVICES: UN APPROCCIO MODERNO AI SISTEMI DISTRIBUITI Luca Canali Stefano Parmesan Martino Salvetti Maicol Zenatti Anno Scolastico 2005 / 2006 WEB SERVICES: UN APPROCCIO MODERNO AI SISTEMI DISTRIBUITI 1 / 27
Web Services: un approccio moderno ai sistemi distribuiti Introduzione...3 Sistemi distribuiti...4 Introduzione a XML... 7 ATTRIBUTI E NAMESPACE...7 CONVALIDA DTD... 8 Web Services... 9 ARCHITETTURA...9 CICLO DI VITA...10 SCENARI DI UTILIZZO...11 SOAP... 12 Errori... 13 WSDL... 16 UDDI... 17 Netfinity...19 STORIA...19 Pyfinity...19 nfinity... 19 netfinity... 20 LATO CLIENT...21 gsoap... 21 Name Mangling...22 Qualche funzionalità:... 22 Backup Database...26 Sicurezza... 26 Funzioni rubrica... 26 SVILUPPI FUTURI... 27 WEB SERVICES: UN APPROCCIO MODERNO AI SISTEMI DISTRIBUITI 2 / 27
Introduzione Lo sviluppo di Internet, specialmente negli ultimi anni, ha subito una rapida evoluzione dovuta principalmente al mutamento dei suoi ambiti di utilizzo. Mentre agli albori di tale sviluppo le pagine statiche riuscivano a soddisfare le necessità degli sviluppatori, successivamente è nata l'esigenza di avere pagine variabili nel tempo e che interagissero con l'utente. Quindi si è passati da una programmazione semplice basata su linguaggi di markup come l'html a una programmazione vera e propria basata all'inizio su tecnologie come CGI (Common Gateway Interface), in seguito su linguaggi interpretati come PHP e ASP. Alle porte del terzo millennio Internet ha subito una nuova metamorfosi. Ora le aziende non si accontentano più di avere una semplice presenza sul Web ma hanno la necessità di utilizzarlo come mezzo strategico di comunicazione. Da un punto di vista tecnico sono quindi nati i primi application framework che letteralmente significa infrastruttura di applicazioni le quali ovviamente devono collaborare tra di loro. Il problema principale di questa tecnologia è rappresentato dall'eterogeneità dei protocolli utilizzati che quindi rendono complicata la comunicazione e lo scambio di informazioni. Le prime aziende che si sono mobilitate per sopperire a questo problema furono Microsoft, IBM, Sun Microsystems e Apache Software Foundation che posero le basi per lo sviluppo di un protocollo di comunicazione standard (SOAP: Simple Object Access Protocol) come punto di inizio per un nuovo tipo di applicazione web: i web services. Il funzionamento di questi web services è relativamente semplice. Essi utilizzano un middleware che permette di fornire un'interfaccia di comunicazione comune a tutti indipendentemente dalla piattaforma utilizzata; il tutto in maniera trasparente sia per l'utente che per il programmatore. Un progetto analogo è CORBA (Common Object Request Broken Architecture) che si prefigge come scopo la costruzione di ponti tra i vari linguaggi di programmazione creando architetture distribuite, ma la sua complessità realizzativa ha frenato in parte la sua diffusione. Il vero punto di forza dei web services è rappresentato dal fatto che, a differenza di CORBA, si basa sull'xml (extensible Markup Language) che è un metalinguaggio la cui sintassi e semantica sono indipendenti dall'ambiente e dal linguaggio di programmazione utilizzato. WEB SERVICES: UN APPROCCIO MODERNO AI SISTEMI DISTRIBUITI 3 / 27
Sistemi distribuiti Prima di cominciare con l'analisi dei sistemi distribuiti è doveroso partire dal concetto di sistema centralizzato nato all'inizio degli anni Sessanta con l'avvento dei mainframe in cui si concentravano tutte le forze elaborative ai quali venivano collegati dei semplici terminali chiamati stupidi. Successivamente, verso gli anni Ottanta si diffondono le prima LAN (Local Area Network) dove ogni componente è dotato di una sua autonomia e permette la condivisione delle risorse. Infine, grazie all'avvento dell'architettura client server e delle reti WAN (Wide Area Network) è nato all'inizio degli anni Novanta il concetto di sistema distribuito. Qual è la reale differenza fra una rete normale e un sistema distribuito? In una rete l'esistenza di calcolatori autonomi non è trasparente, ovvero l'utente deve esplicitamente dire a quale macchina si collega e a quale macchina richiede un'elaborazione remota. In sostanza i sistemi distribuiti introducono questa trasparenza. Grazie ad essi ora è possibile far riferimento ai servizi offerti dalle stazioni della rete senza la necessità di conoscerne l'ubicazione. Formalmente, i sistemi distribuiti permettono l'accesso a risorse remote e la condivisione di servizi. Come già accennato nell'introduzione Internet ha subito varie metamorfosi nella sua breve vita, l'ultima delle quali è la fornitura di servizi. Di conseguenza ha visto la luce SOA (Service Oriented Architecture) che non è altro che un'architettura in grado di supportare l'uso di questi servizi attraverso l'introduzione delle seguenti entità: Il fornitore del servizio (provider); Il registro per la descrizione del servizio. In pratica esso contiene tutte le informazioni necessarie per l'utilizzo del servizio; Il cliente che richiede il servizio. Ecco come queste entità interagiscono tra di loro: Publishing: pubblicazione del servizio dal fornitore sul registro; Service location: Il client ricerca in quali registri si trova il servizio di cui ha bisogno; Binding: Il client si collega al servizio per usarlo. Analizziamo ora alcune delle tecnologie esistenti per implementare tutto ciò. WEB SERVICES: UN APPROCCIO MODERNO AI SISTEMI DISTRIBUITI 4 / 27
L'architettura più famosa è senz'ombra di dubbio CORBA (Common Object Request Broker Architecture) definita formalmente dall'omg (Object Management Group) nel 1991. In pratica si è utilizzato uno dei principi base della programmazione ad oggetti, l'incapsulamento, e lo si è applicato in funzione del superamento delle barriere esistenti nelle infrastrutture hardware e software di un sistema distribuito; ovvero si è riusciti a mettere in comunicazione due oggetti localizzati su due differenti architetture incapsulandoli in altri oggetti omogenei tra di loro. Dato che questi oggetti risiedono su macchine diverse è nata la necessità di creare un canale di comunicazione, l'object Request Broker (ORB). Un'altra tecnologia molto utilizzata è RPC (Remote Procedure Call) che equivale alla chiama a procedura locale soltanto che questa avviene in remoto. Lo svantaggio rispetto a CORBA è che RPC richiede l'uniformità delle piattaforme. Le altre tecnologie che meritano di essere menzionate sono RMI (Remote Method Invocation) e DCOM ma la loro trattazione sarà discussa in altra sede. Il fattore che accomuna queste architetture è la creazione di un middleware che permetta la comunicazione in maniera trasparente all'utente. Il reale problema è rappresentato dal fatto che comunque queste tecnologie sono eterogenee perché ognuno utilizza il proprio standard ed è difficile inoltre comunicare con reti differenti a causa dei firewall. Il primo passo verso la risoluzione di questi problemi è l'utilizzo di XML, un linguaggio di markup WEB SERVICES: UN APPROCCIO MODERNO AI SISTEMI DISTRIBUITI 5 / 27
come l'html, ma a differenza di quest'ultimo è in grado di dare struttura e significato ai dati. Inoltre, dato che è in formato testuale, è indipendente dalla piattaforma e facilita le operazioni di debugging perché è comprensibile non solo per la macchina ma anche per il programmatore. Superato questo scoglio non resta che il problema di come descrivere le informazioni da trasportare. Ovviamente anche la descrizione deve essere standardizzata altrimenti le tre entità potrebbero usufruire di protocolli diversi tra di loro. Visto che ci stiamo muovendo verso un'architettura orientata ai servizi non ci basta più scambiare solo informazioni. Analizziamo quindi le differenze principali fra servizi e informazioni. 1. Il servizio deve essere accessibile a tutti; 2. Il servizio deve essere facilmente reperibile; 3. Il servizio deve essere in grado di descrivere ciò che può fornire. Il raggiungimento di questi obiettivi lo si è avuto con l'introduzione dei web services. Le loro caratteristiche principali sono le seguenti: 1. I web services devono essere in grado di comunicare tra di loro; 2. Essi possono essere sincroni (necessitano di una risposta) o asincroni (comunicazione one way); 3. Affidabilità; 4. Sicurezza; 5. Modularità. Quindi per la loro realizzazione sono stati introdotti: Un protocollo basato su XML per lo scambio dei dati (SOAP: Simple Object Access Protocol); Un linguaggio che permetta la descrizione del servizio (WSDL: Web Services Description Language); Un metodo per pubblicare e cercare i servizi (UDDI: Universal Description Discovery and Integration). Il protocollo di trasmissione utilizzato è l'ormai collaudatissimo HTTP. WEB SERVICES: UN APPROCCIO MODERNO AI SISTEMI DISTRIBUITI 6 / 27
Introduzione a XML Prima di parlare di XML è doveroso citare il capostipite di tutti i linguaggi di markup, lo SGML (Standard General Markup Language). È stato ideato per la creazione di linguaggi ed è stato standardizzato dall'iso nel 1986. L'XML è un insieme di regole che permettono la suddivisione del documento in parti e sottoparti con l'ausilio dei tag. L'obiettivo era realizzare un linguaggio simile allo SGML ma più semplice e per fare ciò si sono basati sull'html che al tempo riscuoteva parecchio successo per la sua intuitività. Ovviamente anche l'xml è stato standardizzato. L'ente che si è occupato di questo è il W3C (World Wide Web Consortium). Nel documento di standardizzazione il W3C dice cosa è e cosa non è l'xml: XML deve essere facilmente implementato su Internet; XML deve essere utilizzato dal più ampio numero di applicazioni; XML deve essere compatibile con SGML; Deve essere facile scrivere dei programmi che processano un documento XML; I documenti XML devono essere leggibili dai programmatori; I documenti in XML devono essere di facile realizzazione; Il markup XML non deve essere necessariamente conciso; Il progetto di un documento XML deve essere mirato e conciso; Le caratteristiche opzionali di XML devono essere ridotte al minimo. L'aspetto più importante è rappresentato dal fatto che questo linguaggio è in grado di fare una netta distinzione fra contenitore e contenuti. ATTRIBUTI E NAMESPACE Mentre i tag rappresentano l'infrastruttura del documento, gli attributi rappresentano delle informazioni su questa infrastruttura; ovvero sono dei metadati relativi all'elemento in cui sono stati dichiarati. Gli attributi esistono anche nell'html, ma in questo caso sono statici e forniscono informazioni solo sull'aspetto del documento. In XML, invece, non hanno questo scopo per il semplice motivo che non è un linguaggio di formattazione ma di descrizione. WEB SERVICES: UN APPROCCIO MODERNO AI SISTEMI DISTRIBUITI 7 / 27
L'utilizzo degli attributi non è soggetto a regole ben precise; devono essere usati a discrezione del programmatore. Un'altra funzionalità molto interessante di questo linguaggio sono i namespace che permettono il riutilizzo di tag già definiti in altri documenti. CONVALIDA DTD Esiste la possibilità di creare delle regole personalizzate enunciandole in un DTD, ovvero un documento che ne definisce la struttura e il vocabolario. Bisogna prestare particolare attenzione a questa funzionalità perché i parser XML possono essere di due tipi: convalidanti e non convalidanti. Nel primo caso è possibile eseguire il parsing del documento XML corredato da DTD perché controlla automaticamente la correttezza formale. Infine esiste la possibilità di inserire altre informazioni come immagini, suoni ecc... Questi elementi vengono chiamati entità e possono essere di due tipi: interne (definite all'interno del DTD) o esterne (link). WEB SERVICES: UN APPROCCIO MODERNO AI SISTEMI DISTRIBUITI 8 / 27
Web Services Ora che abbiamo introdotto i concetti base sui sistemi distribuiti e sull'xml siamo pronti ad analizzare in maniera più approfondita il funzionamento di un servizio web. Il capitolo partirà con lo studio dell'architettura su cui si basano e poi prenderemo in esame il protocollo SOAP per la trasmissione dei messaggi, il linguaggio WSDL per la descrizione dei servizi e di come sia possibile pubblicare e ricercare un web service con l'ausilio di UDDI. Ma prima di tutto ciò proviamo a dare una definizione il più possibile formale di web services. In base alla definizione presente nel documento Web Services Architecture Requirements a W3C Working Draft 29 april 2002 un web service è un applicativo software identificato da un URI, in cui l'interfacciamento e l'interazione sono definite, descritte e scoperte, tramite un dialetto XML, e supporta direttamente l'interazione con altre applicazioni software utilizzando l'xml come linguaggio per i messaggi e i protocolli base di internet per la comunicazione. ARCHITETTURA Nel documento appena citato vengono descritte anche le caratteristiche che un web service deve possedere per poter essere definito standard. Le principali sono: Interoperabilità; Affidabilità; Web friendly: ovvero la capacità di adattarsi alle esigenze del web, quindi deve basarsi su un sistema di codifica standard come XML, di utilizzare URI per l'identificazione della tecnologia e HTTP per il trasporto dei dati; Sicurezza; Scalabilità ed espandibilità. Come enunciato nel primo capitolo per SOA anche i web services possiedono le stesse tre entità che fanno parte del ciclo di vita di un servizio: 1) Provider; 2) Registry; 3) Client. WEB SERVICES: UN APPROCCIO MODERNO AI SISTEMI DISTRIBUITI 9 / 27
Nell'idea originale di SOA il sistema è di tipo centralizzato client server. I web services invece optano per un sistema decentralizzato basato sul peer to peer (P2P). Passiamo ora all'analisi dei protocolli. SOAP: Come detto nei capitoli precedenti serve per lo scambio di informazioni ed è basato anch'esso come tanti altri su XML. Successivamente sono nati uno schema con il relativo namespce. Il punto di forza di questo protocollo è che non è necessaria una conoscenza approfondita di piattaforme o linguaggi di programmazione da parte dell'utente, basta saper inviare e ricevere messaggi SOAP. UDDI: È una delle due specifiche per il rilevamento di servizi web. L'alternativa è DISCO (DISCOver). Entrambi sono in grado di riunire servizi comuni su un server e di fornire un link ai documenti schema che possono essere richiesti. WSDL: Anch'esso si basa su XML ed è in grado di fornire una descrizione del servizio web. Le principali informazioni che fornisce sono: Reperimento dell'uri; Metodi e proprietà supportati dai servizi; Tipo di dati; Protocollo di comunicazione. CICLO DI VITA Il ciclo di vita di un web service si suddivide principalmente in 6 fasi: 0) Pubblicazione del web service in un registro in modo che sia reperibile dai client. Il web service deve ovviamente essere corredato dal suo WSDL; 1) Facciamo richiesta a un nodo UDDI di un determinato servizio web attraverso un web service pubblico; 2) Il registro fornisce una lista di risultati; 3) Vengono forniti URI relativi a documenti WSDL; WEB SERVICES: UN APPROCCIO MODERNO AI SISTEMI DISTRIBUITI 10 / 27
4) Seguiamo l'uri del documento WSDL scelto; 5) Dopo un analisi del documento WSDL costruiamo un oggetto proxy per poter interagire con il servizio web. Tutte le tecnologie sviluppate finora per i web services necessitano la presenza di un contenitore, Il contenitore è un sistema che fornisce un supporto tecnologico per le esigenze richieste. Tutte le implementazioni che conosciamo sono basate sui web server eccezion fatta per J2EE di Sun Microsystem e.net framework di Microsoft. Da un punto di vista del server nel nostro progetto viene utilizzato il web server httpd 2.0 sviluppato da Apache Software Foundation con PHP 4.3 (Hypertext Preprocessor) come linguaggio di scripting server side con la libreria NuSOAP per la realizzazione dei web services. Dal punto di vista del client, invece, dato che è stato sviluppato in C ed in C++ viene sfruttata la potenzialità offerta dalla libreria gsoap che permette un livello di astrazione tale da potersi concentrare solo sulla logica del programma e non dipendere dalla logica dettata da una semplice API SOAP (la particolarità di questa libreria verrà discussa nei prossimi capitoli). Da un punto di vista strettamente funzionale il client web service deve solo essere capace di inviare, ricevere e interpretare i messaggi SOAP. Fatto molto interessante è che un client può essere un altro web service. SCENARI DI UTILIZZO I scenari di utilizzo dei web service sono principalmente sette: 1. Fire and Forget: Descrive una one way operation senza garanzie; 2. Un sistema one way ma con garanzia dove il trasmettitore vuole ricevere la conferma di ricezione. È utile quando si devono trasmettere informazioni importanti; 3. One way con documenti incorporati; 4. Request Response : Ad ogni messaggio SOAP ricevuto viene inviato un messaggio appropriato; 5. Servizio di notifica (asincrono); 6. Sistema di notifica transazionale (comunicazione fra web services per la registrazione di una WEB SERVICES: UN APPROCCIO MODERNO AI SISTEMI DISTRIBUITI 11 / 27
transazione distribuita); 7. Ottenere un documento WSDL tramite un web service ed immagazzinarlo in registri. SOAP Questo protocollo è stato standardizzato la prima volta l'8 aprile 2000. L'ultima versione è la 1.2 ed è stata approvata il 26 giugno 2002. Per la standardizzazione di questo protocollo sono stati stilati due documenti: SOAP 1.2 framework: definisce la struttura dei messaggi SOAP e di come questi interagiscono come mezzo per scambiare informazioni o come sistemi RPC; SOAP 1.2 adjuncts: Definisce il modo di rappresentare gli oggetti all'interno del messaggio. Il protocollo SOAP è costituito da: Busta SOAP (SOAP Envelope). Essa definisce: struttura generale per esprimere cos'è un messaggio; chi deve occuparsi del messaggio; se è facoltativo o obbligatorio. Regole di encoding di SOAP. Definisce il modo in cui le interazioni devono essere codificate e serializzate; Rappresentazione delle RPC all'interno di SOAP. Un messaggio SOAP è suddiviso in un envelope (busta) che contiene un header e un body che possono contenere qualsiasi informazione in formato XML. Come detto in precedenza la libreria SOAP permette di incapsulare le RPC. Per utilizzare SOAP RPC è necessario: L'indirizzo del target; Nome della procedura o del metodo; WEB SERVICES: UN APPROCCIO MODERNO AI SISTEMI DISTRIBUITI 12 / 27
Identificazione degli argomenti da passare al metodo; Un metodo di separazione degli argomenti. Errori Per gli errori SOAP esiste un envelope specifico chiamato Fault Envelope. Se si verifica un errore in fase di elaborazione in un messaggio SOAP viene generato il seguente codice Queste informazioni sono quelle indispensabili che vengono sempre incluse, ma possono essere presenti anche altre informazioni opzionali. In SOAP 1.2 viene definito il ruolo dell'header nella gestione degli errori. Un errore di questo tipo fa riferimento ad imprevisti accaduti solo ed esclusivamente nel corpo del messaggio. Ciò significa che anche il body volendo può contenere il messaggio d'errore, ma solo l'header ha tutte le informazioni dettagliate. Per questi tipi di errore è stato creato un namespace apposito. Inoltre SOAP 1.2 prevede anche degli errori dedicati a RPC i quali sono definiti nel nuovo WEB SERVICES: UN APPROCCIO MODERNO AI SISTEMI DISTRIBUITI 13 / 27
namespace e hanno rpc: come prefisso. I due possibili errori sono: rpc:procedurenotpresent rpc:badarguments Passiamo ora all'analisi di come SOAP gestisca gli allegati. L'introduzione degli allegati è dovuta al fatto che la gestione di dati binari in SOAP è alquanto complicata. Si è pensato quindi di utilizzare uno standard chiamato SwA (SOAP with Attachments) che permette appunto di allegare ad un messaggio SOAP un qualsiasi file binario grazie all'ausilio del formato MIME (utilizzato per gli allegati nelle e mail). MIME in pratica suddivide il messaggio in diversi blocchi attribuendo a ciascuno di essi un attributo MIME che lo identifichi. Ora non ci resta che capire come viaggiano i messaggi SOAP. I web services per la trasmissione utilizzano principalmente i protocolli HTTP e SMTP. Ipotizziamo che ci siano un nodo trasmettitore (chiamato comunemente Hop) ed un nodo ricevitore (chiamato comunemente Peer) ciascuno dei due identificato da un URI. Entrambi i protocolli in esame sono protocolli standard di Internet e si posizionano sopra TCP e quindi occupano il livello di sessione e presentazione del modello di riferimento ISO / OSI. Nel caso di HTTP esistono due modi per inviare le informazioni, utilizzando i metodi POST o GET. Nel primo caso si include l'intero XML nell'header HTTP in modo da ricevere la risposta nel body HTTP. Il messaggio nell'intestazione viene inviato nel seguente modo: POST /Reservations HTTP/1,1 Host: silix.org Content-Type: application/soap+xml; charset= utf-8 Content-Length: nnnn <?xml version= 1.0?>... WEB SERVICES: UN APPROCCIO MODERNO AI SISTEMI DISTRIBUITI 14 / 27
La risposta quindi finisce nel body: Con GET le cose sono differenti, infatti la risposta è un messaggio SOAP inserito nel body mentre nell'header non va nessun documento XML. Esempio: GET /silix.org/pagina?variabile= valore HTTP/1.1 Host: silix.org Accept: text/html, application/soap+xml Da questo header si può vedere che gli unici documenti accettati sono di tipo text/html e application/soap+xml. Per quanto concerne l'altro protocollo, SMTP, esso è adibito all'invio delle e mail, quindi inviare un messaggio SOAP con questo protocollo equivale proprio ad inviare un e mail. Lo scenario tipico è quello Fire and Forget perché l'invio di un messaggio di posta elettronica è di tipo one way; in linea di massima possiamo utilizzarlo anche nello scenario dove è presente la notifica perché SMTP fra le varie funzionalità offre anche il Delivery Status Notification che WEB SERVICES: UN APPROCCIO MODERNO AI SISTEMI DISTRIBUITI 15 / 27
permette un controllo a livello di protocollo. WSDL Il WSDL è il linguaggio per la descrizione dei servizi web. L'idea generale è quella di creare una serie di end point che siano in grado di comunicare tra di loro. Il WSDL è anche un Interface Description Language (IDL) ed esso definisce: I tipi di dato; I messaggi; Il tipo di comunicazione che ogni messaggio necessita. La sua vera potenzialità è rappresentata dal fatto che si possono scrivere i messaggi di scambio senza dover specificare il protocollo di rete adibito al trasporto. Un file WSDL si suddivide in due parti principali: una parte definisce l'implementazione (con gli attributi Service e Port), l'altra parte definisce l'interfaccia del servizio descrivendo i messaggi, i metodi e il tipo di dati supportati con i relativi marcatori. I principali tag di un documento WSDL sono i seguenti: <definitions> rappresenta la radice di tutto il documento e contiene tutti namespace che vengono utilizzati; <documentation> è un tag opzionale e contiene un link ad una documentazione più comprensibile da parte dell'utente; <import> equivale all'#include in C ed in C++. È molto utile perché permette di rendere il tutto più modulare; <type> contiene il tipo di dati che ci sono negli altri tag; <message> serve per definire i dati che verranno scambiati dai Web Service nel corso del WEB SERVICES: UN APPROCCIO MODERNO AI SISTEMI DISTRIBUITI 16 / 27
servizio; <PortType> specifica un insieme di funzionalità supportate dal web service e definisce le operazioni eseguibili dall'endpoint dove risiede il servizio; <ServiceType> come dice il nome stesso definisce il tipo di servizio offerto; <binding> specifica il protocollo e il formato dei dati da trasportare, nel caso di HTTP specifica se bisogna utilizzare il metodo GET o il metodo POST; <service> identifica il servizio web e definisce l'endpoint. UDDI È un progetto molto ambizioso che si prefigge lo scopo di realizzare un sistema per la pubblicazione e la descrizione di servizi web. Da un punto di vista pratico si vuole creare un framework indipendente da qualsiasi tipo di piattaforma idoneo per realizzare questi obiettivi. Confrontandolo con l'architettura SOA, UDDI rappresenta il registro dove i clienti possono ricercare i servizi di cui hanno bisogno. UDDI è costituito da due elementi principali: 1. UDDI XML Schema for Business Description serve per stilare dei documenti XML che rispondono ad un determinato Schema per la descrizione dei vari elementi di un'attività di qualsiasi genere; 2. Web based registry: Questi dati sono disponibili tramite un'interfaccia via browser o tramite servizi pubblicati su SOAP. In pratica quando un'azienda realizza un servizio web la prima cosa che fa è la registrazione presso un sito UDDI. Il cliente che richiede un determinato servizio si collega ad un sito UDDI e analogamente ad un motore di ricerca interroga la base di dati UDDI in base ad alcuni criteri e ottiene le informazioni necessarie per usufruire del servizio. Un azienda può registrare tre diversi tipi di informazioni: Pagine bianche, ovvero le informazioni sull'azienda; Pagine gialle, ovvero le informazioni sul servizio offerto; Pagine verdi, ovvero le informazioni di carattere tecnico sul servizio offerto. WEB SERVICES: UN APPROCCIO MODERNO AI SISTEMI DISTRIBUITI 17 / 27
In linea di massima UDDI è un insieme di servizi web che effettuano tre operazioni: 1. Registrazione; 2. Pubblicazione; 3. Ricerca. WEB SERVICES: UN APPROCCIO MODERNO AI SISTEMI DISTRIBUITI 18 / 27
Netfinity Il progetto netfinity permette di utilizzare il servizio offerto da Vodafone Italia per l'invio di sms dal Web tramite il portale 190.it. netfinity Server Side rende disponibili le primitive per l'invio dei messaggi e la gestione della rubrica centralizzata mediante web Services. La rubrica implementa una complessa e articolata gestione dei gruppi di contatti. Ad ogni utente in fase di registrazione verrà assegnata una password, memorizzata in forma crittografata nel database, per garantire la privacy ed evitare modifiche non richieste alla rubrica. STORIA Pyfinity Il progetto Pyfinity è nato nel 2005 per rendere disponibile ai nostri utenti un servizio non documentato che Vodafone Italia forniva ai suoi dipendenti. Esso consisteva nell'inoltrare via sms il testo delle e-mail mandate a determinati indirizzi. L'autenticazione avveniva solo con il controllo del dominio di provvenienza delle e-mail; è quindi stato sufficiente falsificare il mittente per convincere il server Vodafone a processare i nostri messaggi. Pyfinity è stato scritto in Python, un linguaggio di scripting general purpose molto potente, scelto per la sua semplicità e per la completezza della documentazione, anche in italiano. Lo script nella sua ultima versione, Pynfinity 0.4.4 (2 gennaio 2006), implementa anche una rubrica tramite file CSV, che rende snello l'utilizzodel software malgrado l'interfaccia a caratteri. nfinity nfinity è un progetto parallelo a Pynfinity e ha avuto lo scopo di fornire un'interfaccia grafica (GUI) allo script in Python. Esso è stato sviluppato in ambiente Borland C++ Builder ed è quindi disponibile solo per l'ambiente Windows, a differenza di Pynfinity che è compatibile con qualsiasi piattaforma che disponga dell'interprete Python. La comunicazione fra i due programmi avviene in modo rudimentale tramite file temporanei. Per evitare questa situazione è nato netfinity WEB SERVICES: UN APPROCCIO MODERNO AI SISTEMI DISTRIBUITI 19 / 27
netfinity Con netfinity abbiamo voluto spostare su un server pubblico i compiti svolti da Pynfinity e lasciare sul client solo l'interfaccia con l'utente finale. Questo passaggio ci ha costretti ad abbandonare Python in favore di PHP; sia per la scarsa documentazione sull'uso del linguaggio via web, sia perché sul nostro server pubblico era installata la versione 2.0 di Python (rilasciata nel 2000). Com'era prevedibile Vodafone Italia modificò o sospese il servizio d'inoltro degli sms via e-mail, così il 1 marzo 2006 netfinity perse lo scopo di esistere. Col tempo un'idea più legale e duratura avanzò nei nostri progetti: utilizzare i servizi messi a disposizione dal portale 190.it. Come si vede dallo schema logico ogni messaggio viene mandato dal client al server Silix.org via Web Service; esso apre delle connessioni HTTP con il server Vodafone 190.it, che gli consentono di effettuare il login e successivamente mandare uno o più messaggi. Il progetto prevede la suddivisione principale in due parti, una lato client ed una lato server. A loro volta anch'essi vengono suddivisi in due sottoprogetti. WEB SERVICES: UN APPROCCIO MODERNO AI SISTEMI DISTRIBUITI 20 / 27
LATO CLIENT Per quanto concerne il lato client un sottoprogetto ha lo scopo di creare l'interfaccia grafica dell'utente e di interfacciarsi al secondo sottoprogetto che è adibito alla creazione di una libreria dinamica (DLL Dynamic Link Library) che sia in grado di comunicare con il web service lato server. Il programma è (almeno inizialmente) sviluppato per ambiente windows con il Borland C++ Builder 5 per l'interfaccia grafica, che è uno dei pochi strumenti sul mercato che permette lo sviluppo di applicazioni RAD (Rapid Application Development) in C++. Per la DLL invece si utilizza il compilatore GCC (GNU Compiler Collection). Questa scelta è stata obbligata a causa dell'utilizzo della libreria gsoap per l'interfacciamento con il web service. gsoap Questa libreria è molto particolare per come ci si interfaccia con essa; per capire realmente il suo funzionamento leggiamo la seguente traduzione della documentazione ufficiale del progetto: Il kit di sviluppo open source gsoap offre un binding tra XML e C/C++ per la costruzione facilitata di Web services SOAP/XML in C e C++. Molti toolkit per i Web Services in C++ adottano una vista centrata su SOAP e offrono un'api che richiede l'uso di librerie di classi per le strutture dati specifiche di SOAP. Questo forza l'utente ad adattare la logica dell'applicazione a queste librerie. In contrasto gsoap fornisce invece un'api SOAP trasparente attraverso l'uso di tecnologie di compilazione collaudate. Queste tecnologie sfruttano lo strong typing per mappare gli schemi XML alle definizioni C/C++. WEB SERVICES: UN APPROCCIO MODERNO AI SISTEMI DISTRIBUITI 21 / 27
Il compilatore gsoap genera serializzatori XML efficienti per i tipi di dati nativi e definiti dall'utente all'interno del codice C/C++. Come risultato, l'interoperabilità SOAP/XML è raggiunta con una semplice API che libera lo sviluppatore dal dover conoscere tutti i dettagli che stanno dietro a WSDL e SOAP, permettandogli di concentrarsi sulla logica del programma. Il compilatore permette in sostanza al codice C/C++ esistente di esporre tramite SOAP servizi e informazioni che possono essere condivisi con altri Web Services in maniera semplice ed intuitiva senza costringere lo sviluppatore a stravolgere la logica dell'applicazione. Name Mangling Un problema molto interessante che è nato nella creazione della libreria dinamica è rappresentato dal fatto che il C++, a differenza del C, quando una funzione deve essere esportata, il suo nome viene storpiato aggiungendo caratteri che variano da compilatore a compilatore. Questo è dovuto al fatto che il C++ è un linguaggio orientato agli oggetti e supporta l'overloading delle funzioni. Ciò significa che il nome delle funzioni (e anche delle classi) non è univoco all'interno del sorgente; per sopperire a questo problema il compilatore modifica appunto il nome. Per evitare che ciò accada la funzione deve essere linkata in stile C ponendo il codice fra i blocchi #ifdef cplusplus extern C { #endif /* definizione della funzione */ #ifdef cplusplus } #endif Qualche funzionalità: Menu principale (tasto blu): Mostra / nascondi gruppi vuoti: permette di nascondere o di mostrare i gruppi vuoti a seconda che gia` lo siano o meno. Mostra / nascondi edit numero singolo: permette di nascondere o di mostrare la edit per inviare un WEB SERVICES: UN APPROCCIO MODERNO AI SISTEMI DISTRIBUITI 22 / 27
messaggio a un numero non presente in rubrica, presente nel gruppo di default. Disconnetti: permette di tornare alla pagina di login per poter accedere eventualmente con un altro utente. Opzioni: apre la schermata di impostazioni di netfinity (descritta in seguito) About: mostra un piccolo about che indica come contattarci... Esci: chiude netfinity Menu dei gruppi (click con il tasto destro del mouse su un gruppo): Seleziona tutto: seleziona tutti i contatti nel gruppo Deseleziona tutto: deseleziona tutti i contatti del gruppo Nuovo gruppo: permette di creare un nuovo gruppo. Una finestra chiedera` il nome del nuovo gruppo da creare Ordina alfabeticamente: ordina alfabeticamente i contatti all'interno del gruppo Modifica: permette di modificare il nome del gruppo. Muovi: permette di spostare il gruppo in un'altra posizione. Metti in testa il gruppo che vuoi venga aperto all'avvio di netfinity! Elimina: elimina il gruppo. ATTENZIONE: non verra` eliminato il gruppo aperto, ma il gruppo su cui hai cliccato con il tasto destro! Menu dei contatti (click con il tasto destro del mouse su un contatto o sulla lista vuota di un gruppo): Nuovo contatto: permette di creare un nuovo contatto. Una finestra chiedera` il nome e il numero. Modifica: modifica il contatto selezionato Muovi: permette di ordinare a piacere i contatti all'interno del gruppo... Copia in...: copia il contatto selezionato in un altro gruppo. Un contatto copiato in tale modo e` in realta` lo stesso contatto presente due volte, quindi modificando il suo nome o il suo numero, esso viene modificato in entrambi i gruppi. Sposta in...: sposta il contatto selezionato in un altro gruppo. Elimina: elimina il contatto selezionato. Altre funzionalita`: -La pressione di CTRL + ENTER invia il messaggio, simulando la pressione del tasto "invia" -La pressione di CTRL + BACKSPACE pulisce il testo del messaggio e deseleziona tutti i contatti, WEB SERVICES: UN APPROCCIO MODERNO AI SISTEMI DISTRIBUITI 23 / 27
simulando la pressione del tasto "pulisci" -E` possibile ridurre netfinity ad icona, lasciandolo nella TrayBar. Una qualunque comunicazione, come ad esempio l'avvenuto invio di un messaggio, verra` segnalata con un popup." Opzioni: Generale: Impostazioni: permette di gestire alcune importanti funzionalita` di netfinity: il controllo di esecuzione (controlla all'avvio se una versione di netfinity e` gia` in esecuzione, evitando di aprirne altre), riduzione automatica ad icona (riduce ad icona netfinity quando si invia un sms) e il log degli errori (salva in un file di testo "netfinity.log" tutti gli errori che si verificano) ShortCuts: permette di scegliere le scorciatoie per ridurre ad icona netfinity (di default CTRL+SHIFT+FRECCIA GIU) e per recuperarlo dalla tray bar (di default CRTL+SHIFT+FRECCIA SU) Connessione: Login: si puo` impostare netfinity in modo che effettui il login automaticamente all'avvio, inserendo nome utente e password che si volgiono utilizzare. Proxy: se si utilizza un proxy per accedere a internet, si puo` indicarlo a netfinity da qui`. Account: Modifica profilo: permette di modificare le proprie informazioni personali presenti sul server di netfinity, quali password, nome utente e password del 190 e il numero di messaggi che si vuole condividere Importa rubrica: importa la rubrica di precedenti versioni di netfinity (piu` precisamente nfinity, il software precedente) in realta` si tratta di un semplice file cvs con i contatti memorizzati come "nomeutente,numero,gruppo" Esporta rubrica: esporta la propria rubrica in un file cvs con i dati separati da virgole. Utile per copie di backup. LATO SERVER Per quanto concerne l'applicativo lato server i due sottoprogetti sono relativi (1) alla gestione della rubrica e (2) all'invio vero e proprio del messaggio grazie all'interfacciamento con il sito 190.it. Il server viene eseguito su una macchina equipaggiata di sistema operativo GNU/Linux con web WEB SERVICES: UN APPROCCIO MODERNO AI SISTEMI DISTRIBUITI 24 / 27
server httpd 2.0.58 dell'apache Software Foundation e PHP 4.3 come linguaggio di scripting general purpouse lato server. La scelta del DBMS è caduta per forza di cose su MySQL 4.1 perché la società che ospita il nostro sito web (www.silix.org) non lascia alternative. Le funzionalità di questo DBMS sono veramente limitate; non permette l'utilizzo né delle foreign key né l'utilizzo di trigger o stored procedure. Di conseguenza la gestione del DBMS via PHP diventa più complessa. Passiamo ora ad analizzare il database che abbiamo creato per la gestione della rubrica. Progettazione concettuale: Progettazione logica: Utente (nome, password, informazioni utente) Gruppo (nomeusr, nomegrp) FOREIGN KEY nomeusr REFERENCES Utente(nome) Contatto (id, nome, numero) GrpCon (nomeusr, nomegrp, idcon) FOREIGN KEY nomeusr, nomegrp REFERENCES Gruppo FOREIGN KEY idcon REFERENCES Contatto WEB SERVICES: UN APPROCCIO MODERNO AI SISTEMI DISTRIBUITI 25 / 27