Infos 2007 paper template



Scaricare 78.41 Kb.
02.02.2018
Dimensione del file78.41 Kb.


Supporto per la gestione distribuita in tempo reale di risultati tennistici tramite Web Services

Francesco Cantarini



Università degli studi di Bologna, Viale Risorgimento 2,40136 Bologna

Reti di Calcolatori LS – Prof. Ing. Antonio Corradi

A.A. 2006/07
Abstract

Con il trascorrere del tempo e la maturazione delle tecnologie, si é visto come le risorse che il web rende disponibili si siano trasformate da "risorse Web" in "applicazioni Web", cioè un insieme di pagine create e opportunamente messe in relazione in modo da formare una sorta di prodigioso “puzzle” capace di compiere complicate elaborazioni un tempo inimmaginabili. Con il Web in passato si era "limitati" ad utilizzare i risultati ottenuti da un’elaborazione e a trasformare dei dati in contenuto informativo, rappresentandoli nelle forme consentite dall'HTML, secondo una logica relativamente molto semplice: digitazione dell’indirizzo della pagina dinamica, elaborazione da parte del server del codice nella pagina e restituzione del risultato. Si é assistito poco a poco ad una migrazione delle applicazioni locali: il software installato sulle nostre macchine ha cominciato a spostarsi verso il Web fino a diventare dei servizi Web ed essere distribuito dal Web. Basti pensare ai diffusissimi siti che gestiscono la posta elettronica, senza il bisogno di installare un qualche software client. Ecco che si é passati piano piano dall'utilizzo dei risultati forniti dal Web all'utilizzo del codice fornito dal Web.

É stata così definita la specifica dei Web Services che sono proprio dei servizi che mettono a disposizione il codice da utilizzare per costruire delle applicazioni più complesse.

Immaginiamo di montare una applicazione utilizzando diverse applicazioni installate su diversi server attraverso Internet.

Scendendo più in dettaglio, immaginiamo di utilizzare dei metodi e delle proprietà di un oggetto installato non sullo stesso server web ma su un altro server qualsiasi situato in Africa o in Asia.

La tecnologia che permette di utilizzare la logica applicativa, oppure più semplicemente parlando, il codice di programmazione messo a disposizione di chi ne fa richiesta, è appunto alla base del concetto di Web Service.

Certo, ci sono altre tecnologie che hanno permesso di fare cose simili ma la novità insita nei Web Services sta nel fatto che questa volta, per consentire la comunicazione tra client e server, non si utilizzano dei protocolli specifici e proprietari ma un nuovo protocollo in fase di standardizzazione dal W3C, proposto non solo da Microsoft ma anche da IBM e altri grossi produttori.

Per testare questa specifica é stato realizzato un’applicazione di supporto alla gestione distribuita in tempo reale di tornei di tennis, utilizzando come tecnologia il framework Axis fornito da Apache per realizzare sistemi di integrazione basati su SOAP.

Sono stati presi in considerazione anche alcuni aspetti relativi alla qualità del servizio, alla sicurezza e alla pubblicazione dei servizi (quest’ultimo attraverso jUDDI, progetto open source sviluppato anch’esso da Apache).

Keywords: Web Services; Axis; jUDDI


1. Introduzione

I sistemi informatici moderni sono progettati per essere interconnessi: le tipologie di sistemi operativi, le tecnologie software e hardware sono differenti, e nessuna ha il sopravvento sulle altre. Con l’appoggio crescente da parte delle maggiori industrie

del software, l’architettura basata sui servizi promette di fornire quello che molti middleware non sono mai riusciti a realizzare appieno: l’utilizzo di servizi a

prescindere da dove e come siano realizzati.

I diffusi middleware RMI,CORBA e D-COM lavorano in modo simile. Le differenze si trovano piú

nelle diverse caratteristiche che sono supportate come anche nel livello di complessità. Tutti si risolvono in uno stretto accoppiamento tra client e server dove si possono usare ognuno dei middleware.

Ad ogni modo molte delle già citate tecnologie (RMI, CORBA,COM) coinvolgono un’intera curva di apprendimento. Nuove tecnologie e linguaggi devono essere appresi per implementare questi servizi. Anche i Web Services sono basati su un set standardizzato di regole e specifiche che lo rendono più portabile, questo però non é il caso con le tecnologie menzionate precedentemente.

Diversamente dalle attuali tecnologie basate su componenti, i Web Services non sono accessibili mediante un protocollo specifico di modello ad oggetti bensì utilizzano protocolli e formati dati che sono standard per il Web, come HTTP (Hypertext Transfer Protocol) e XML.


2. Web Services e SOA

Nel mondo eterogeneo del Web nasce la necessità di avere un modo “standard” per esporre un software su una rete attraverso un’interfaccia comprensibile da tutte quelle aziende che, volendo far interagire le proprie applicazioni con quelle di altre compagnie, riconoscono tale standard. É così che sono

introdotti i Web Services e viene adottata l’Architettura Orientata ai Servizi (SOA).
I Web Services sono Componenti Software accessibili attraverso i normali protocolli in uso su Internet (HTTP, XML, SMTP, ecc...).

Il modello dei Web Services non si pone in concorrenza con le tradizionali architetture a componenti (CORBA, COM+) ma le affianca, permettendo di esporre componenti già esistenti verso nuovi client, scritti magari con linguaggi diversi ed operanti su architetture diverse.

La forza del modello dei Web Services è di utilizzare un set base di protocolli disponibili ovunque, permettendo l’interoperabilità tra piattaforme molto diverse e mantenendo comunque la possibilità di utilizzare protocolli più avanzati e specializzati per effettuare compiti specifici.
La Service-Oriented Architecture é

un’architettura concettuale che non fa riferimento a nessuna particolare implementazione. Essa pone delle specifiche condizioni che i componenti del sistema devono rispettare e caratteristiche che tale sistema deve necessariamente avere.

I Web Services sono invece una nuova tecnologia, che si basa su standard e che fornisce un facile metodo di interfacciamento tra le applicazioni. Questa tecnologia non é legata all’architettura SOA ma ha molti punti di contatto con essa e sistemi che utilizzano i Web Services, sfruttando tutte le loro potenzialitá, implementano esattamente un’architettura di tale tipo.

Le principali caratteristiche che un servizio SOA deve avere sono :




  • essere autocontenuto e modulare.

  • essere definito da un’interfaccia ed indipendente dall’implementazione.

  • essere ricercabile e recuperabile dinamicamente.

  • essere debolmente accoppiato con altri servizi (loosely coupled

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

  • fornire un’interfaccia possibilmente a “grana grossa” (coarse-grained): deve mettere a disposizione un basso numero di operazioni,

  • cioè poche funzionalità, in modo tale da non dover avere un programma di

controllo complesso.

  • essere realizzato in modo tale da permetterne la composizione con altri.

I protocolli alla base del modello dei Web Services sono quattro:

XML è lo standard usato per rappresentare i dati

trasportati

SOAP è lo standard usato per definire il formato

dei messaggi scambiati

WSDL è lo standard usato per descrivere i

parametri, i metodi ed i valori di ritorno dei servizi

UDDI è lo standard promosso dall’omonimo

consorzio, e serve per rintracciare i servizi sulla

rete.

Fig. 1 Interazione con Web Services

Il modello dei Web Services, da un punto di vista orientato ai servizi, è basato su tre ruoli fondamentali e sulle necessarie interazioni ciascun ruolo. In figura 2 sono illustrati ruoli e interazioni.

I tre ruoli sono:



  1. Service Provider – E’ una piattaforma che fornisce l’accesso al servizio. Per esporre un’applicazione come un servizio, il provider deve fornire un accesso basato su un protocollo standard e una descrizione standard del servizio (meta data).

  2. Service requestor o user – In generale, è un’applicazione che invoca o avvia un’interazione con un servizio. Il service requestor e il service provider devono condividere le stesse modalità di accesso e interazione col servizio.

  3. Service registry – E’ un registro presso il quale i service provider possono pubblicare il servizio e i service requestor possono trovare i servizi desiderati. Il service registry deve fornire una tassonomia consistente dei Web Services per facilitarne la scoperta, e una descrizione dettagliata dell’azienda che fornisce il servizio e del servizio stesso.


Fig. 2 Ruoli e interazioni






Le operazioni che consentono l’interazione tra i tre componenti del modello sono:



  1. Publish – Il service provider invia la descrizione del servizio, che ospita, al service registry. Questo classifica il servizio e lo pubblica in maniera tale che un service requestor possa trovarlo.

  2. Find – Il service requestor interroga il service registry per ottenere la descrizione del servizio richiesto.

  3. Bind – Il service requestor utilizza i dettagli presente nella descrizione del servizio per contattare il service provider mediante il quale interagisce con l’implementazione del servizio.


2.1 SOAP
La tecnologia Web Service è essenzialmente basata sul messaggio e quindi era necessario adottare un insieme di regole per poter inoltrare una richiesta client e costruire quindi un messaggio che possa essere capito dal server. Il server di conseguenza utilizzerà lo stesso formato per la risposta. Si è voluto scegliere un metodo standard per rappresentare i dati scambiati e la scelta non poteva che ricadere su XML. Il trasporto di questi dati in formato XML è affidato al protocollo HTTP. Dalla combinazione di XML e HTTP nasce proprio il protocollo SOAP (Simple Object Access Protocol, il protocollo standard per i Web Services.

Un messaggio SOAP è un documento XML che contiene i seguenti elementi:



  • Envelope, identifica il documento come un messaggio SOAP

  • Un elemento Header opzionale, contenete informazioni specifiche per l'applicazione, che non sarà approfondito in questa sede ma che permette di definire alcuni messaggi, anche con diversi destinatari nel caso il messaggio dovesse attraversare più punti di arrivo

  • Body è un elemento indispensabile che contiene le informazioni scambiate dalle richieste/risposte

  • Fault è un elemento opzionale che fornisce informazioni riguardo ad eventuali errori manifestati durante la lettura del messaggio

Le regole principali per realizzare un messaggio SOAP sono le seguenti:

  • Deve essere ovviamente codificato con XML

  • Deve utilizzare il SOAP Envelope namespace

  • Deve utilizzare il SOAP Encoding namespace

  • Non deve contenere il collegamento ad un DTD e non deve contenere istruzioni per processare XML

2.2 WSDL

Una volta definito il modo in cui comunicare è necessario sapere cosa mettere a disposizione e cosa è possibile rendere disponibile con un Web Service.

Se si può utilizzare un metodo di un oggetto, allora è necessario come minimo sapere come si chiama il metodo, che parametri accetta, di che tipo e come va interpretato il risultato ottenuto.

E' proprio questo il compito del file WSDL (Web Service Description Language), un file in formato XML che descrive il Web Service in termini di metodi richiamabili, nomi dei parametri, tipi, ecc

E' una sorta di contratto tra client e server, che si accordano in questo modo sulle informazioni da scambiarsi.

Il documento WSDL separa la descrizione astratta dei dati da scambiare (Message) e delle operazioni realizzate dal servizio (PortType) con l’implementazione concreta (service) che consente di effettuare l’effettiva chiamata al servizio remoto. La parte concreta del documento, dunque, contiene un insieme di Port, in altre parole indirizzi URL e informazioni specifiche per effettuare il binding mediante il protocollo SOAP.


2.3 UDDI
Universal Discovery, Description ed Integration (http://www.uddi.org) è un consorzio a cui partecipano numerose aziende che ha come scopo quello di favorire lo sviluppo, la scoperta e l'interoperabilità dei servizi Web. UDDI fornisce un database distribuito su cui si possono registrare le aziende ed i servizi da loro esposti.
E' sostanzialmente un servizio di naming come il DNS (che però opera a livello pi basso) o LDAP. L'interrogazione dei registri può essere

effettuata da browser o con il SOAP.

Le informazioni gestite da UDDI sono di tre tipi:


  • pagine bianche: contengono informazioni anagrafiche delle aziende

  • pagine gialle: contengono le liste dei WS divisi per categoria

  • pagine verdi: contengono informazioni tecniche sui WS come l'URL dove risiedono e gli eventuali file WSDL

UDDI in pratica può essere visto come una specie di insieme di pagine gialle elettroniche cui si rivolgono i service requestor per cercare i Web Services desiderati, o anche solo le informazioni su una certa azienda, e i service provider per pubblicare il loro profilo e i loro servizi.
3. Realizzazione del progetto: Gestione distribuita in tempo reale di risultati tennistici
Obiettivo del progetto era quello di sviluppare un’applicazione utilizzando argomenti a scelta rilevanti per i temi del Corso.

Si è ragionato così su che tipo di applicazione distribuita progettare in modo da mettere in pratica alcune tra le conoscenze apprese.

L’idea è stata quella di realizzare un'applicazione distribuita di supporto informatico a tornei di tennis in cui il sistema doveva essere composto da un'applicazione che permettesse, a un utente autorizzato, l'aggiornamento su un DataBase dei dati delle partite la cui visualizzazione doveva essere possibile mediante browser da PC, mediante dispositivo palmare,attraverso TV digitale o da applicazioni dedicate per la visualizzazione delle statistiche in ambito broadcast-TV.

Poiché i vari attori del sistema dovevano operare da remoto, e dato che l'applicazione doveva essere distribuita, si è pensato di progettare un middleware che permettesse di far comunicare le parti rendendole però allo stesso tempo indipendenti in modo tale che, nel caso si dovesse apportare una modifica ad una di esse, non si dovesse per forza riprogettare tutto il sistema. Inoltre questo "livello intermedio" doveva permettere l'accesso ai dati da differenti dispositivi dotati solo di una interfaccia di accesso al middleware.

Si è pensato di utilizzare i Web Services come middleware per diversi motivi: sia per il "disaccoppiamento" che l'interfaccia standard che espongono rende possibile fra il sistema utente ed i Web Services stessi, come discusso nei capitoli precedenti di questo articolo, e che ben si adatta per lo sviluppo di questo supporto; sia perché è una tecnologia interessante e di rilievo; sia perché è stata poche volte considerata dagli studenti nei progetti precedenti presenti on-line.

Dati i limiti temporali (dovuti all’esame) e i costi, si é implementata solo l’applicazione relativa all’aggiornamento e la applet che permettesse la visualizzazione delle informazioni tramite bowser.


3.1 Tecnologie utilizzate


      1. Apache Axis

Axis è un framework per realizzare sistemi di integrazione basati su SOAP. Il prerequisito fondamentale per l’installazione di Axis è la configurazione di un servlet container come Tomcat.

I Web Services sono stati creati con l’IDE Eclipse opportunamente aggiornato col plugin WTP (Web Tools Platform) che permettere l’utilizzo di Axis con Eclipse.



      1. Tomcat

Tomcat è un software open source la cui funzionalità principale è quella di Web Application Server, ovvero capace di gestire e supportare le pagine JSP e le servlet. Nelle ultime versioni però sono state aggiunte funzionalità tra cui quella di supporto ai Web Services attraverso l’utilizzo del framework ApacheAxis.





      1. Apache HTTP Server

Apache http Server è un webserver per il protocollo http, disegnato per poter girare come un processo standalone ed è un prodotto open source distribuito con il codice sorgente. Caratteristica fondamentale è che è portabile su tutte le versioni di Unix, Windows,BeOs, sui mainfraime…




      1. Modulo jk

Brevemente questo modulo si installa su Apache HTTP Server e permette di “chiamare” Tomcat quando necessario. E’ in pratica un connettore che permette di collegare Apache e Tomcat.


3.1.5 jUDDI
jUDDI è l’implementazione Java delle specifiche di UDDI, ed è un progetto Open Source sviluppato anch’esso da Apache. JUDDI mette a disposizione il servizio UDDI attraverso l’uso di un database che nel nostro caso è fornito da MySQL, dato che è gratuito.


      1. JAX-RPC

La tecnologia utilizzata per l’invocazione dei web services i questo progetto è JAX-RPC (Java API for XML-Based Remote Procedure Call) che permette l’invocazione dei web service, impostando in modo semplice e veloce i parametri di tale invocazione. Questa tecnologia mette a disposizione inoltre il supporto per il mapping dei tipi da XML a Java e viceversa.

JAX-RPC, che necessita di SOAP (sopra HTTP), fornisce il supporto per il modello di scambio di messaggi SOAP. Inoltre SAAJ (SOAP

Attachment API for Java), utilizzato da JAX-RPC, fornisce una API Java per la costruzione e la manipolazione di messaggi SOAP con allegati. E’

possibile trasferire, all’interno di allegati al messaggio SOAP, vari tipi di documento, come ad esempio documenti XML o immagini.

JAX-RPC permette di utilizzare diverse tecniche per invocare i web service, a seconda delle esigenze e del livello di dinamicità che si vuole ottenere.

I possibili mrtodi di invocazione di un web

service sono:

• Stub creato da WSDL

• Dynamic Proxy

• Dynamic Invocation Interface (DII)

• Dynamic Discovery and Invocation (DDI).




        1. Stub creato da WSDL

Con questa metodologia prima della fase di esecuzione viene creato uno stub, specifico per la piattaforma che stiamo utilizzando, nella la fase di mapping delle informazioni da WSDL a Java.

Lo stub è formato da una classe Java che implementa una SEI (Service Endpoint Interface). La Service Endpoint Interface è la rappresentazione

Java delle operazioni del web service che sono descritte dall’elemento Port-Type all’interno del documentoWSDL, vale a dire un’interfaccia Java che definisce i metodi utilizzati dal client per interagire con il web service. La SEI viene generata prima della fase di esecuzione tramite l’uso di appositi tool per il mapping da WSDL a Java.

Lo stub è quindi una classe che agisce da proxy per un servizio remoto.

Il vantaggio del metodo stub consiste nella sua semplicità; infatti con poche linee di codice si può invocare un web service.

E’ però necessario conoscere, in fase di sviluppo dell’URL, il file WSDL, che deve essere passato al tool di mappingWSDL-to-Java per la generazione

dello stub ed inoltre lo stub non è portabile perché dipendente dalla specifica piattaforma su cui è stato creato.





        1. Dynamic Proxy

Questo metodo utilizza un proxy per invocare la specifica operazione del web service che è una classe Java che, come nel caso dello Stub, implementa la SEI; questo proxy viene però creato a tempo di esecuzione ed ottenuto dal metodo getPort(), di JAX-RPC Service, il quale prende il nome della porta relativa al servizio che vogliamo invocare ed il nome della classe che rappresenta la SEI che viene implementata dal proxy.

Questo metodo è definito dynamic, cioè dinamico, perchè il proxy è creato a tempo di esecuzione. E’ comunque necessario conoscere a development-time l’interfaccia dell’operazione che viene invocata.

Il vantaggio fornito da questo metodo è la creazione di codice portabile ed indipendente dalla piattaforma.




        1. Dynamic Invocation Interface (DII)

Il metodo Dynamic Invocation Interface, pur complicando in parte il codice, fornisce un livello di dinamicità più elevato.

JAX-RPC Service non viene più utilizzato per ottenere un proxy, bensì per l’istanziazione di JAX-RPC Calls, utilizzate per l’invocazione del web service.

Il vantaggio di utilizzare DII sta nel fatto che per invocare una procedura remota non è necessario conoscere il file WSDL e non è richiesta la generazione di classi, come avviene nei casi di Dynamic Proxy e Static Stub.

Si devono però conoscere l’indirizzo del servizio, le operazioni messe a disposizione ed i parametri da queste accettati. Queste informazioni vengono utilizzate dal client DII dinamicamente runtime.



        1. Dynamic Discovery and Invocation (DDI)

Dynamic Discovery and Invocation rappresenta la soluzione più dinamica nell’invocazione di web service. Questo metodo è un’evoluzione del DII, con la differenza che con questa metodologia non è necessario conoscere in anticipo l’indirizzo del servizio, le sue operazioni ed i parametri d’ingresso

di queste ultime. Tutte queste informazioni saranno recuperate a tempo di esecuzione grazie al servizio UDDI.

Ecco passi che questo metodo segue:

1. Richiedere al servizio UDDI informazioni relative al web service che vogliamo invocare, fra le quali otteniamo l’URL del file WSDL che lo descrive. Questo può essere fatto utilizzando le librerie UDDI4J.

2. Eseguire il parsing del documento WSDL, ad esempio attraverso l’utility WSDL4J di Axis, ed ottenere le informazioni necessarie all’invocazione del web service come namespace, nome dell’operazione e parametri.

3. Invocare il servizio utilizzando il metodo DII con i valori ottenuti al passo precedente.


    1. Analisi

Analizzando i requisiti del progetto dal punto di vista dei casi d’uso sono stati subito individuati due “attori” principali: l’aggiornatore e il visualizzatore.

Ognuno doveva essere fornito di un’applicazione dedicata che gli permettesse di svolgere le proprie operazioni.



      1. Aggiornatore

Dall’analisi è emerso che l’applicazione di aggiornamento dovesse fornire le seguenti funzionalità:




  • Login: inserimento di username e password;

  • Selezione del torneo/partita;

  • Catalogazione degli eventi della partita in corso (Es. a rete con successo, palla break trasformata, ace, ecc.);

  • Settaggio inizio game,set,tie break;

  • Visualizzazione statistiche e dati del giocatore;

  • Impostazione del tempo, cronometro della partita;

      1. Visualizzatore

A un utente remoto invece doveva essergli reso possibile:




  • La scelta della partita da visualizzare;

  • La visualizzazione dei risultati dei set della partita;

  • La visualizzazione dei dati anagrafici e i successi sportivi degli sfidanti;

  • La visualizzazione delle statistiche relative ad ogni giocatore, comprendenti: %1 servizio, ace, conversione palle break, punti vinti, ecc.




    1. Progettazione dei Web Services

I Web Services che dovevano svolgere la funzione di Middleware nel sistema dovevano essere resi disponibili non solo per un aggiornatore e un utente munito di un browser su pc, ma da una qualsiasi applicazione che avesse bisogno dei servizi forniti.

Si è puntato perciò al disaccoppiamento totale dei WS in modo da renderli indipendenti e facilmente riutilizzabili.

Inizialmente il tutto è stato realizzato in locale (senza simulare il distribuito con un server), sono stati creati due package: serviceConsumer e serviceProvider.

Il primo conteneva le classi relative al lato client (aggiornatore o visualizzatore) mentre il secondo le classi che fornivano i servizi attraverso metodi (ogni classe era un futuro web service). Successivamente le classi sono state trasformate attraverso il framework Axis (o meglio, attraverso il tool WTP) in web services.
Sono stati realizzati 12 Web Services:


  • TestLoginService: verifica username e password;

  • SavePwdService: cambia la password di login;

  • SelectEventService: seleziona i tornei presenti sul database;

  • SelectMatchTypeService: seleziona il tipo di torneo (singolo o doppio);

  • SelectShiftService: seleziona il turno;

  • SelectPlayersService: seleziona gli sfidanti;

  • GetMatchInformation: restituisce le informazioni dell’incontro (giocatori, arbitro, ecc.)

  • GetMatchPointsService: restituisce i punteggi della partita selezionata;

  • GetPlayerInformationsService: restituisce le informazioni relative a un giocatore;

  • GetPlayerStatisticsService: restituisce le statistiche dei giocatori;

  • SavePlayersStatisticsService: salva le statistiche della partita selezionata;

  • SavePointsService: salva i punteggi della partita;




    1. Persistenza dei dati

Il problema della memorizzazione delle informazioni relative alla partita su disco e di come recuperarli, ovvero il problema della “persistenza dei dati”, è stato risolto utilizzando un database Microsoft Acces già esistente. Si è supposto che il DB iniziale sia già aggiornato di partenza con dati anagrafici, storici dei giocatori e con già tutti i calendari dei tornei impostati, in modo da facilitare il compito all’operatore che cataloga la partita sul campo.


Per accedere al database è stata creata una classe ODBCDatabase che, caricando il bridge JDBC-ODBC per la connessione, permette di eseguire le query e gli aggiornamenti.

Questo sistema è stato testato in locale (simulando il distribuito) perciò si è supposto che il DataBase risiedesse dove risiedono i Web Services. E’ stata però creata una classe “intermedia” DBManagerService, i cui metodi sono invocati dai web services, in modo che se si volesse trasferire il DB su un altro nodo basterebbe semplicemente trasformare questa classe in Web Service e il tutto funzionerebbe regolarmente come comunicazione tra WS.




    1. Sicurezza

La comunicazione del sistema poteva essere criptata tramite il protocollo SSL (Secure Sockets Layer) come descritto e spiegato nel seguente link (www.tecnoteca.it/howto/oc4j) ma non è stato necessario dato che le informazioni di un torneo di tennis non sono rilevanti per la privacy e possono viaggiare in chiaro.

E’ stato però utilizzato un algoritmo hash per criptare i due file che contengono rispettivamente username e password per l’autenticazione. La funzione Hash è una funziona univoca operante in un solo senso (ossia, che non può essere invertita) utile per trasformare un testo di lunghezza variabile in una stringa di lunghezza fissa (in questo caso a 160 bit, SHA-1).


    1. Pubblicazione dei Web Services

L’invocazione dei web services in questo progetto è stata affidata alla classe InvokeWS implementata utilizzando il metodo DII di JAX-RPC descritto in questo capitolo al paragrafo 3.1.6.3. Tuttavia in seguito si è voluto pubblicare i web services utilizzando jUDDI e MySQL ma la classe InvokeWS non è stata modificata per rispettare i tempi di consegna. Se si volesse provare a invocare i web services pubblicati basterebbe implementare InvokeWS con la metodologia DDI di JAX-RPC accennata nel paragrafo 3.1.6.4 .


Per la pubblicazione dei WS, sempre effettuata tramite il tool WTP in ambiente Eclipse, si è dovuto installare jUDDI e per fare questo è stato fondamentale disporre di un server Tomcat e configurare un database (MySQL).

Tutte le istruzioni su come installare e configurare questo servizio possono essere trovate in lingua inglese a questo link: www.mail-archive.com/juddi-user@ws.apache.org/msg00472.html




    1. QoS

Se si vogliono migliorare le prestazioni di un sistema è imprescindibile fornire qualità del servizio.

In questo progetto è stato realizzato il load balancing sia per ottimizzare l’utilizzo della memoria da parte di Tomcat, sia per permettere, in caso di caduta di uno dei servlet container, il continuo funzionamento del sistema.

E’ stato considerato il problema della session replication (www.onjava.com/pub/a/onjava/2004/11/24/replication1.html ) ma si è concluso che per questo progetto non era necessario complicare il sistema tramite un meccanismo di replicazione delle copie, infatti replicare una sessione HTTP significa sincronizzare le informazioni relative alla sessione utente su tutti io web container che prendono parte al cluster.

Quando si procede alla installazione di un qualsiasi sistema di replica la prima cosa che si deve valutare è se questa funzionalità è realmente necessaria al sistema altrimenti si rischierebbe di complicarlo e appesantirlo troppo.
Infine si voleva predisporre anche un sistema di monitoring attraverso le API JMX (Java Management Extentions) ma per rispettare i tempi di consegna questa parte non è stata realizzata e forma parte degli “ulteriori sviluppi futuri”.



      1. Load Balancing

Con il termine “load balancing” si intende la ripartizione del carico, vale a dire l’associazione di un URL a cui corrisponde un’applicazione ad un numero arbitrario di Server http e web container.

Il load balancing permette ai client, in caso di bloccaggio di uno o più server, di continuare a usufruire del sistema ridirigendoli verso un’altra applicazione distribuita su un altro container.

Importante è tener conto che tutti i container sono equivalenti fra loro (quando un client inizia la comunicazione con un server, proseguirà sempre con lo stesso) e che il sistema non garantisce il mantenimento della sessione (se in un determinato instante il container si blocca i dati di sessione andranno persi e l’utente dovrà reiniziare la procedura).


In questo progetto, per semplicità, si è utilizzato un unico Apache HTTP Server opportunamente connesso tramite il connettore mod_jk a due web container Tomcat.

Il load balancing permette di ripartire il carico delle chiamate in maniera circolare secondo la modalità round robin pesato (Fig. 3).

Per configurare Apache, Tomcat e il connettore si sono seguite le indicazioni al sito:

http://thought-bytes.blogspot.com/2007/03/how-to-load-balance-tomcat-55-with.html

Fig. 3 Ripartizione circolare del carico




4. Conclusioni e ulteriori sviluppi futuri
Il progetto è stato realizzato solo per un utente che volesse visualizzare le informazioni tramite una pagina web. Si potrebbe estendere il sistema progettando anche le interfacce che permettano la visualizzazione anche tramite palmare, TV digitale o in ambito broadcast-TV.

Alcuni controlli e funzionalita dell’applicazione di aggiornamento andrebbero migliorate.


Il sistema potrebbe essere “ampliato” dal punto di vista “SOA” aggiungendo un Service Bus e un sistema di orchestrazione dei servizi BPEL.
Inoltre, come accennato, andrebbe creato un sistema di monitoraggio che sarebbe utile per rilevare le prestazioni del sistema.
Nel complesso lo sviluppo di questo progetto, anche se limitato solo all’utilizzo del linguaggio Java, ha permesso di comprendere appieno le funzionalità dei web services e di testare l’utilizzo di numerosi strumenti.


BIBLIOGRAFIA



  • Guida Web Service (di Giulio Turetta) – http://xml.html.it/guide/leggi/100/guida web-service/




  • Creating and publishing Web Services to jUDDI - http://www.mail-archive.com/juddi-user@ws.apache.org/msg00472.html




  • Mokabyte: Lo strato web: load balancing e session replication -http://www.mokabyte.it/2004/12/clustering-3.htm




  • WTP: http://help.eclipse.org/help31/index.jsp?topic=/org.eclipse.jst.ws.axis.ui.doc.user/tasks/ttomcatserv.html
  • Using the Eclipse Plug-in for WebSphere Application Server Community Edition - http://www.ibm.com/developerworks/websphere/library/techarticles/0604_sun/0604_sun.html

  • Load Balancing - http://javaoverloaded.wordpress.com/2007/06/26/load-balancing-con-apache-2x-e-tomcat-4x/

  • Tomcat - http://www.eclipsetotale.com/tomcatPlugin.html

  • SOA - http://visualcsharp.it/blogs/articoli/archive/2007/03/29/introduzione-ai-soa-server-oriented-architecture.aspx

  • Service Oriented Architecture and Web Service (di Andrea Polini) - http://www1.isti.cnr.it/~polini/downloads/WS_Unicam.pdf

  • JMX - http://www.mokabyte.it/2003/09/jmx-1.htm

  • Web Services - http://www.dia.unisa.it/~ads/corso-security/www/CORSO-0203/piattaformesviluppowireless/webservices.htm

  • Invoking Web Services with Java clients - http://www.ibm.com/developerworks/webservices/library/ws-javaclient/














©astratto.info 2017
invia messaggio

    Pagina principale