Integració d'un Proxy de serveis web en una xarxa P2P DHT

TREBALL DE FI DE CARRERA TÍTOL DEL TFC: Integració d’un Proxy de serveis web en una xarxa P2P DHT TITULACIÓ: Enginyeria Tècnica de Telecomunicació, especialitat Telemàtica AUTOR: Marçal Sans Niubò DIRECTOR/A: Dolors Royo Vallès DATA: 22 de novembre de 2007 Títol: Integració d’un Proxy de serveis web en una xarxa P2P DHT Autor: Marçal Sans Niubò Director/a: Dolors Royo Vallès Data: 22 de novembre de 2007 Resum L’objectiu d’aquest Treball final de carrera ha estat la implementació d’un Proxy de serveis web dintre d’una xarxa peer-2-peer (P2P) basada en Distributed Hash Table (DHT). Per realitzar aquest treball s’ha utilitzat una xarxa P2P DHT basada en el software FreePastry (Pastry). El punt de partida d’aquest projecte es una ampliació d’un projecte anterior; en el anterior treball es va estudiar i implementar un sistema de publicació i execució de serveis web en una xarxa Pastry DHT. Per tant, el que es pretén amb aquest TFC, es estendre les funcionalitats d’un node de la xarxa, de l‘anterior projecte, per a que sigui capaç de connectar-se a mes d’una xarxa Pastry DHT i pugui actuar de punt d’interconnexió d’aquestes xarxes. D’aquesta manera els nodes d’una xarxa pugui consultar i executar els serveis web publicats en altres xarxes Pastry DHT. Cal remarcar que Pastry es un protocol P2P basat en DHT que crea xarxes amb una topologia lògica d’anell, on cada node conté un tros de la taula de hash. La taula de hash es composa d’un seguit de entrades que relacionen el servei amb un identificador obtingut a partir d'una funció de hash. Per a la gestió i implementació de serveis web hem utilitzat la tecnologia dels WebServices de Axis i el servidor web Apache. La implementació del projecte es pot dividir bàsicament en 3 parts: Implementació de una nova classe principal: s’ha tingut que implementar un nou mètode main per a poder recollir la informació per a connectar el node a diferents xarxes Implementació de un nou sistemes de missatges per a publicació del Proxy: s’ha tingut que crear nous missatges i nous mètodes per a poder descobrir el Proxy a la xarxa Pastry Modificació del sistema de consulta de WebServices: s’han tingut que modificar alguns mètodes existents en el codi a fi de poder introduir el Proxy en el moment que no es troba un WebServices a la xarxa Títol: Integració d’un Proxy de serveis web en una xarxa P2P DHT Autor: Marçal Sans Niubò Director/a: Dolors Royo Vallès Data: 22 de novembre de 2007 Overview The goal of this Final Work of Career has been the implementation of a Proxy of web services in a net peer-2-peer (P2P) based Distributed Hash Table (DHT). To carry out this work has a net P2P DHT based on the software FreePastry (Pastry). The starting point of this project is an extension of an other project; in the former work was studied and implemented a system of publication and execution of web services in a Pastry DHT net. Therefore, the objective of this TFC, is to spread the functionality of a node of the net, of the former project, for that node are capable of connecting besides a net and can act as point of interconnection of these nets. In this way the nodes of a net can consult and execute the web services published in other Pastry DHT nets. It is necessary to remark that Pastry is a P2P protocol based on DHT that creates nets with a ring logical topology, where each node contains a piece of the table of hash. The hash table is composted of a series of entries that relate the service with an identifier obtained from a hash function. For the WebService management and implementation we have used the WebServices Axis technology and the server web site Apache. The implementation of the project can divide in 3 steps: Implementation of a new main class: we need to implement a new method main to be able to pick up the information to connect the node to different nets Implementation of a new systems of messages for publish the Proxy: we need create new messages and new methods to be able to reveal the Proxy to the Pastry net Modification of the WebServices consultation system: we need modify some existing methods in the code to introduce the Proxy in the moment that a WebServices is not found in the net ÍNDEX CAPÍTOL 1. INTRODUCCIÓ....................................................................1 1.1. Objectius..........................................................................................2 1.2. Pla de treball....................................................................................3 CAPÍTOL 2. TECNOLOGIES USADES.............................................................4 2.1. Conceptes telemàtics generals......................................................4 2.1.1. Proxy....................................................................................4 2.1.2. Protocol XML.......................................................................5 2.1.3. Distributed Hash Table (DHT)..............................................5 2.2. La tecnologia Peer-to-Peer (P2P)...................................................6 2.2.1. Propietats de les xarxes P2P...............................................6 2.2.2. Noves aplicacions sorgides de les xarxes P2P...................7 2.2.3. FreePastry............................................................................8 2.3. WebServices...................................................................................10 2.3.1. Estàndards usats................................................................11 2.3.2. Mode de funcionament.......................................................11 2.3.3. Apache WebServices Axis Project.....................................13 CAPÍTOL 3. IMPLEMENTACIÓ DE L’APLICACIÓ..........................................14 3.1. Punt de partida...............................................................................16 3.1.1. Esquema d’objectes de l’aplicació......................................16 3.1.2. Publicació d’un Servei Web................................................21 3.1.3. Cerca d’un Servei Web.......................................................22 3.1.4. Execució d’un Servei Web..................................................23 3.2. Implementació del Proxy...............................................................24 3.2.1. Esquema d’objectes de l’aplicació......................................24 3.2.2. Publicació del Proxy...........................................................27 3.2.3. Cerca d’un Servei Web……………………………………….28 CAPÍTOL 4. PROVES DE L’APLICACIÓ.........................................................33 CAPÍTOL 5. BALANÇOS I CONCLUSIONS……………………………………..41 5.1 Comprovació de la planificació inicial……………………………...41 5.2 Objectius assolits………………………………………………………41 5.3 Millores i ampliacions futures……………………………………..…42 5.4 Conclusions personals…………………………………………..……42 CAPÍTOL 6. BIBLIOGRAFIA……………………………………………………….43 Capítol 1. Introducció 1 CAPITOL 1. INTRODUCCIÓ Aquest treball es centra en l’estudi de dues tecnologies, que en l’actualitat, tenen un gran pes dintre del desenvolupament de les telecomunicacions. Bàsicament ens centrarem en l’estudi i implementació de les xarxes Peer-to-Peer i dels serveis web. Cal remarcar, que aquest TFC és una ampliació d’un TFC ja existent on es va implementar una aplicació usant el software FreePastry per a que es poguessin publicar i executar WebServices d’Axis. Des del principi d’Internet i les telecomunicacions, la filosofia ha estat crear sistemes d’intercanvi d’informació no centralitzats que permetessin gran connectivitat d’usuaris i poca sobrecàrrega del sistema, i que al mateix temps fossin escalables i fàcilment gestionables. Un gran pas cap a aquesta filosofia, han estat les xarxes P2P (Peer-to-Peer) on la gestió dels recursos de la xarxa no recau en un node central; sinó, que cada node contribueix a la gestió de la xarxa. Amb l’aparició d’aquestes xarxes es va trencar amb l’esquema tradicional d’intercanvi de recursos on hi havia un servidor que gestionava les dades i un seguit de clients que es connectaven al servidor per a accedir als recursos; d’aquesta manera, els nodes passen a esdevenir tant servidors com clients de la xarxa. En aquest cas, pel nostre projecte, ens centrarem concretament en l’estudi i desenvolupament del software P2P FreePastry. FreePastry és un protocol P2P basat en DHT (Distributed Hash Table), programat en Java i de lliure distribució. Hem escollit el protocol FreePastry perquè te implementada una interfície anomenada Application que ens permet el desenvolupament de noves aplicacions sobre aquest protocol. Un altre dels propòsits inicials de les telecomunicacions, fou el poder crear sistemes on es poguessin executar i gestionar serveis remotament, amb independència de la tecnologia en què es basessin. Partint d’aquesta base es van desenvolupar els serveis web. La tecnologia dels serveis web es basa en una col·lecció de protocols i estàndards (oberts) utilitzats per intercanviar dades entre aplicacions independentment del llenguatge de programació en el que han estat implementades i de la plataforma on s’executen. Per a protocols i estàndards oberts entenem aquelles especificacions que estan disponibles públicament per a aconseguir una tasca específica i que es poden usar sense haver de pagar tasses pel seu ús o complir un seguit de condicions. Aquests estàndards permeten la compatibilitat i la interpolaritat entre diferents components i dispositius ja que qualsevol desenvolupador de software o hardware pot accedir a les especificacions del producte. La tecnologia per a implementar i gestionar WebServices que hem usat en aquest treball ha estat la del projecte Apache-Axis. El projecte Axis és una implementació de SOAP ("Simple Object Access Protocol" ). SOAP és un protocol estàndard creat per Microsoft, IBM i altres; actualment supervisat per 2 Integració d’un Proxy de serveis web en una xarxa P2P DHT la W3C que defineix les directrius per a que dos objectes de diferents processos es puguin comunicar, tant localment com remotament mitjançant l’intercanvi de missatges XML. 1.1 Objectius El principal Objectiu d’aquest treball és la creació d’un Proxy que permeti accedir a WebServices publicats en altres xarxes. Per a tal propòsit hem fet un estudi detallat de les xarxes P2P (Xarxa FreePastry) i dels WebServices (Projecte Apache-Axis) per a posteriorment poder modificar el codi d’un node Pastry per a que realitzi les funcions de Proxy de serveis web entre diferents xarxes FreePastry. A fi de complir aquest objectiu principal hem dividit la feina en varis objectius secundaris: Estudi de les tecnologies a usar: en aquest primer objectiu marcat, el que es pretén és fer un estudi profund tant de la tecnologia FreePastry, com dels WebServices Axis a fi de poder comprendre el seu funcionament i poder desenvolupar posteriorment aplicacions pròpies sobre aquestes tecnologies Estudi del projecte anterior: en el TFC que prenem com a punt de partida, el que es pretenia era crear una xarxa Pastry on es poguessin publicar i executar WebServices d’Axis. Per tant, el nostre següent objectiu, ha estat l’estudi de l’aplicació creada en aquest projecte inicial. Implementació del Proxy: Aquest darrer objectiu l’hem desglossat en tres subobjectius. 1. Desenvolupament d’una classe principal (mètode main): Un cop estudiat i comprès el sistema de desenvolupament en el que treballarem i el codi des del qual partirem, el següent pas ha estat el crear una nova classe que contingués un mètode main específic, per al node que realitzarà les tasques de Proxy, ja que el mètode main implementat en l’anterior treball no contempla la possibilitat de connectar el node a diferents xarxes. 2. Implementació de nous missatges i classes: s’han hagut de crear nous missatges i funcions per a poder descobrir i interactuar amb el node que fa de Proxy dins de la xarxa, ja que l’antic TFC no contemplava aquesta possibilitat. 3. Adaptació del codi existent: per últim, un cop el Proxy està connectat a totes les xarxes i aquestes l’han reconegut; el nostre següent objectiu a estat el d’adaptar el codi ja escrit per a que quan un WebServices buscat no es troba a la xarxa, s’enviï la comanda de cerca al Proxy i aquest pugui gestionar la cerca a les restants xarxes. Capítol 1. Introducció 3 1.2 Pla de treball En aquest capítol es detalla la planificació realitzada per a dur a terme tots els objectius exposats anteriorment, explicant les tasques en les que s’ha dividit el projecte i els recursos necessaris per a cadascuna. 1.2.1 Descripció de les tasques a realitzar Considerant que el projecte es realitzarà en 420 hores durant 15 setmanes, treballaré 28 hores setmanals, aproximadament 5 hores i mitja diàries. El projecte consta de 5 tasques, cada una d’elles amb un número d’hores determinat. El resultat determinarà en quin moment es pot donar per finalitzada la tasca. Estudi de les tecnologies a usar (56 hores) En aquest primer objectiu marcat, el que es pretén es fer un estudi profund tant de la tecnologia FreePastry, com dels WebServices. Estudi del projecte anterior (56 hores) En aquesta etapa del projecte estudiarem el codi que es va utilitzar en el projecte original. S’estudiarà l’estructura d’objectes que conformen el node i l’intercanvi de missatges que es produeix al realitzar les accions de publicació, cerca i execució d’un WebService Desenvolupament del Proxy (56 hores) Un cop estudiat i comprès el sistema de desenvolupament en el que treballarem i el codi des del qual partirem, el següent pas ha estat el crear una nova classe que ens permeti connectar el node a diverses xarxes. Implementació de l’aplicació (140 hores) Aquesta tasca es basa en programar el Proxy i modificar l’aplicació existent per a complir els objectius d’aquest TFC. Proves de l’aplicació (8 hores) Aquesta tasca consisteix en realitzar les proves necessàries per assegurar un correcte funcionament Redacció de la memòria (76 hores) Aquesta etapa consisteix en crear el document final. El resultat serà la memòria definitiva d’aquest TFC. Presentació (28 hores) Finalment, es faran les transparències per a preparar la presentació oral del TFC i un guió per seguir a l’hora de presentar el projecte. 4 Integració d’un Proxy de serveis web en una xarxa P2P DHT CAPÍTOL 2. TECNOLOGIES USADES 2.1 Conceptes telemàtics generals 2.1.1 Proxy Entenem com a Proxy, informàticament parlant, tota aplicació o dispositiu que gestiona operacions en nom d’altres. Així doncs, podem parlar de diferents tipus de Proxys en funció de les tasques que realitzin. El Proxy més conegut és el Proxy web, aquest s’encarrega de gestionar les peticions d’accés a webs en nom dels clients que té connectats. L’ús d’aquesta tecnologia comporta grans avantatges per a la xarxa encara que també pot ocasionar inconvenients si no s’usa adequadament. Les principals avantatges són: Control: Al ser el Proxy l’encarregat de gestionar les peticions dels clients, resulta mes fàcil poder gestionar els permisos d’accés per a cada client. Rapidesa: Habitualment els Proxys van dotats d’una memòria cache on emmagatzemen temporal o definitivament el resultat de les peticions. D’aquesta forma si una petició és produïda per varis clients o ja ha estat produïda amb anterioritat, la resposta es serveix directament de la memòria cache; reduint així el retard en la comunicació. Filtrat: Al ser el Proxy el que te el control sobre les peticions dels clients es poden implementar en ell, polítiques de filtrat per a les peticions. Anonimat: En una xarxa amb un Proxy, el que està accedint realment als recursos és ell; per tant la identificació del client no apareix en la consulta final que fa el Proxy al servidor. Això pot suposar un desavantatge si el servidor requereix identificació específica del client. Com ja hem comentat abans si els Proxys no estan ben dimensionats o situats adequadament poden ocasionar un seguit de inconvenients tal com: Colls d’ampolla: Al ser un punt per on han de passar totes les comunicacions dels clients, si el Proxy no està ben dimensionat es poden produir col·lapses en aquest punt fent que el retard en la comunicació augmenti considerablement. Privacitat: Com a punt intermedi que gestiona peticions i respostes del client; al Proxy s’emmagatzema informació. Aquesta, depèn de quina fos, podria comprometre la privacitat del client. Desincronització: Al emmagatzemar les respostes en la memòria cache. Es pot donar el cas, si el proxy no està ben configurat, que es serveixin respostes que no estan actualitzades. Capítol 2. Tecnologies usades 5 En el cas del nostre projecte, el que pretenem, es crear un Proxy que gestioni la consulta i accés dels clients d’una xarxa Pastry als serveis webs allotjats en altres xarxes Pastry adjacents al Proxy. 2.1.2 Protocol XML Extensible Markup Language (XML) és un metallenguatge simple i flexible derivat de l’estàndard SGML (ISO 8879) i desenvolupat per la W3C. Originalment, aquest llenguatge va ser dissenyat per a resoldre els problemes que plantejava la publicació i consulta electrònica a gran escala de continguts amb independència de la plataforma emprada per a publicar o consultar aquestos. L’estàndard SGML constitueix un sistema per a la organització i etiquetatge de documents que la ISO va estandarditzar en 1986. Aquest estàndard en cap moment marca unes etiquetes predefinides sinó que únicament ens especifica les regles a seguir per etiquetar un document. En aquest projecte ens hem valgut de l’estàndard XML per a definir l’estructura dels missatges que s’intercanvien els nodes. 2.1.3 Distributed Hash Table (DHT) Les Distributed Hash Tables (DHT) són un sistema descentralitzat dissenyat per oferir serveis i operacions de recerca en xarxes de computadors. Les DHT consten d’un espai de claus, on cada clau és un resum de hash de m-bits de longitud. L’espai de la taula es troba distribuïda equitativament entre els nodes que conformen la xarxa. D’aquesta forma cada node gestiona únicament l’espai de claus assignades a ell. La forma que prèn l’espai generat per la DHT i l’esquema utilitzat per a particionar-lo depèn de cada una de les xarxes estructurades. Figura 2.1: Esquema de com s’organitza una DHT en una xarxa P2P Pastry 12 Integració d’un Proxy de serveis web en una xarxa P2P DHT Figura 2.4: Esquema de la publicació, consulta i execució d’un WebService Tal com podem observar en la figura 2.4, per a que una aplicació pugui executar un WebService, ha d’haver un primer pas. En aquest primer pas, el servidor que conté el WebService fa una publicació de l’arxiu WSDL en un catàleg UDDI conegut tant pel servidor com per l’aplicació. Un cop publicat l’arxiu WSDL, en el moment que l’aplicació requereixi l’ús del WebService realitzarà una consulta a l'UDDI mitjançant el protocol SOAP, a fi d’obtenir l’arxiu descriptor WSDL. Amb aquesta acció l’aplicació obté totes les dades necessàries per establir connexió amb el servidor. Un cop parcejat l’arxiu WSDL i obtingudes les dades de connexió, l’aplicació estableix una comunicació via SOAP amb el servidor del WebService on invoca la funció requerida i transmet els paràmetres necessaris per a que aquesta s’executi. Un cop executada la funció, el servidor retorna via SOAP el resultat a l’aplicació, la qual la mostra a l’Usuari. El format del resultat de l’execució de la funció també va descrit en l’arxiu WSDL. Cal recordar que totes aquestes transicions són transparents a l’usuari, en cap moment es requereix la participació d’aquest; ni en el moment de consulta del WSDL, ni en el d’establiment de connexió amb el servidor. L'únic moment en el que es pot requerir la intervenció de l’usuari seria a l’hora d’escollir els valors dels paràmetres d’entrada de la funció si aquesta ho requerís. Per a l’usuari l’execució de la funció és com si es produís en local. Per a poder implementar els WebServices en el nostre projecte hem utilitzat la plataforma del projecte Apache WebServices Axis que ens ofereix uns scripts per a poder crear els arxius WSDL i les aplicacions clients a partir de un WebService. Capítol 2. Tecnologies usades 13 2.3.3. Apache WebService Axis Project Axis es un motor SOAP; un marc on es poden desenvolupar clients i servidors de WebServices basats en SOAP. Actualment, Axis treballa sobre Java encara que en implementacions més recents s’està començant a treballar en el llenguatge C++. Axis a part del motor SOAP també porta implementades altres aplicacions que faciliten la creació i publicació de WebServices, aquestes són:  Un servidor stand-alone simple; també trobem un conjunt de pluguins per incorporar la tecnologia dels WebServices a servidors com podria ser el Tomcat.  Incorpora un seguit d’utilitats que permeten crear archius WSDL a partir de les aplicacions en Java. També inclou una extensa ajuda sobre el llenguatge WSDL  Tutorials d’exemple i una aplicació per poder monotoritzar els paquets TCP/IP a fi de poder comprendre i estudiar la informació que el protocol SOAP s’intercanvia El projecte Axis és la tercera generació del projecte Apache SOAP; aquest projecte començà a IBM amb el nom de SOAP4J. A finals de l’any 2000 els comitès encarregats d’Apache SOAP v2 van començar a discutir com aconseguir una màquina més flexible, configurable i capaç d’implementar SOAP amb l’emergent protocol XML que estava estandarditzant la W3C. 14 Integració d’un Proxy de serveis web en una xarxa P2P DHT CAPÍTOL 3. IMPLEMENTACIÓ DE L’APLICACIÓ Com ja hem comentat anteriorment, aquest projecte és l’ampliació d’un TFC ja existent. En el anterior TFC, el que es pretenia era crear un sistema de publicació, consulta i execució de WebServices en una xarxa P2P basada en DHT. A fi de realitzar tals propòsits van ser escollides la plataforma WebServices Axis per a crear els WebServices i FreePastry per a implementar la xarxa P2P. Cal remarcar que els WebServices publicats per un node no s’executen a través de la xarxa P2P, sinó que aquestos, estan allotjats en un servidor web (Tomcat) extern a la xarxa FreePastry. Aquesta és una característica original del projecte anterior i que no modificarem ja que no és un dels objectius que ens hem proposat en aquest TFC. En aquesta aplicació realment el que està succeint és que la pròpia xarxa Pastry està fent la funció de catàleg UDDI dels WebServices de la xarxa Figura 3.1 Esquema de la xarxa resultant en la aplicació Originalment Per a gestionar els WebServices publicats en cada anell Pastry, tal com podem observar a la figura 3.1, l’aplicació consta d’una llista que s’emmagatzema en la taula DHT pròpia de Pastry. En aquesta llista per a cada WebService publicat, creem una entrada de dades amb els següents camps. Nom del WebService: En aquest cap introduïm el nom amb el qual després podrem buscar i executar el WebService. Url del Servidor Web: En aquest camp el que introduïm és la direcció web del servidor que allotja el WebService a publicar Capítol 3. Implementació de l’aplicació 15 Url on es troba l’arxiu WSDL: En aquest camp emmagatzemen l’adreça web en la que es troba l’arxiu descriptor WSDL del WebService. Descripció: En aquest camp s’introdueix una petita descripció sobre el WebService. Prenent com a punt de partida l’esquema de xarxa comentat anteriorment, el que pretenem amb el nostre TFC, és crear un nou tipus de node anomenat Proxy. Aquest node té la propietat de poder-se connectar a més d’una xarxa Pastry. Amb aquesta modificació la topologia de xarxa que obtenim és la que podem observar a la figura 3.2 Figura 3.2 Esquema de la xarxa resultant amb la introducció del Proxy Un cop creat el nou node Pastry, hem modificat el mòdul de cerca dels nodes antics de tal manera que si un WebService no es troba en l’anell al qual pertany el node; automàticament el node que el cerca, es connecta al Proxy i li demana que busqui el WebService a les xarxes a les quals esta connectat. Un cop feta la recerca en totes les xarxes a les qual pertany el Proxy, aquest respon al node amb tants missatges com xarxes a les que esta connectat. En aquest missatge ve un “null” si no ha estat trobat en aquella xarxa el WebService o la informació de connexió si s’ha trobat en aquella xarxa. La informació que retorna el Proxy és: el Nom del WebService, l’Url del Servidor Web que conté el WebService, Url del fitxer .wsdl descriptor de les funcions del WebService i una breu descripció de les funcions que realitza el WebService Un cop el node té tots els missatges de resposta, un per cada xarxa a la que el Proxy està connectat, els avalua i escull el WebService que més li convé per a executar. Cal esmentar que en aquest punt es podria implementar una política especifica per a escollir el WebService però en el nostre TFC aquest no 16 Integració d’un Proxy de serveis web en una xarxa P2P DHT era un dels objectius, per tant, en el nostre cas s’escull executar el primer dels WebServices trobat. 3.1 Punt de partida 3.1.1 Esquema d’objectes de l’aplicació El projecte original consta d’un objecte principal anomenat MyMain, aquest objecte és l’encarregat d’inicialitzar els objectes PastryNode i MyApp. El PastryNode és un objecte que ve especificat en el software de FreePastry; aquest objecte és el que inicialitza totes les variables i objectes necessaris per a poder crear un node Pastry i unir-lo a la xarxa. L’objecte MyApp és una implementació de la interface Application (Aquesta interface també ve proporcionada pel software de Pastry). La interface Applicaction està preparada per a poder desenvolupar noves aplicacions sobre el node per a una xarxa P2P FreePastry . Per l’intercanvi d’informació entre els nodes s’han implementat un seguit de missatges XML; aquests es troben descrits en la llibreria MyMsgXML. 3.1.1.1 La classe MyMain La classe MyMain consta dels següents mètodes: connect  És un mètode públic de tipus void. Aquest mètode és l’encarregat de crear el nodePastry i l’objecte MyApp associat al node. Per a poder inicialitzar el PastryNode necessitem 3 paràmetres; aquests són: el port per on escoltarà la xarxa el nostre node, l’adreça IP del bootstrap node (el bootstrap node, es refereix a un node que ja pertany a la xarxa ) i el port per on el bootstrap node escolta la xarxa. Aquests paràmetres són passats com arguments al iniciar el programa. pintaMenuPrincipal  És un mètode públic de tipus void. Aquest mètode conté el menú de totes les funcions que pot realitzar la nostra aplicació. Aquest menú el podem observar en la figura 3.3 publishWebService És un mètode públic del tipus void. En aquest mètode es fan la petició per teclat de les dades necessàries per a poder publicar un WebService com podrien ser nom del WebService, direcció URL del servidor que l’allotja, etc. searchWebService  És un mètode públic del tipus void. Aquest mètode és l’encarregat de gestionar totes les dades per a poder fer la cerca d’un WebService. Capítol 3. Implementació de l’aplicació 17 listWebService  És un mètode públic del tipus void. Quan es fa la crida a aquest mètode, s’obté una llista amb el nom i la descripció de tots els WebServices que hi ha publicats en el moment en la xarxa P2P execWebService  És un mètode públic del tipus void. Aquest mètode és l’encarregat de contactar amb el servidor del WebService i executar-lo. isReady  És un mètode públic del tipus boolean. Aquest mètode porta el sincronisme entre l’objecte MyMain i l’objecte MyApp. En l’objecte MyMain es recullen totes les dades per a poder executar les funcions dels nodes, aquestes però, van programades en l’objecte MyApp. Per tant, aquesta funció s’encarrega de comprovar si l’objecte MyApp ha finalitzat la seva feina. Figura 3.3 Captura de l’aspecte del menú del Programa amb la crida a la funció 3.1.1.2 El NodePastry El nodePastry utilitza la capa de transport Socket per a comunicar-se. Aquesta capa és una llibreria que forma part del codi font de FreePastry (exactament dins de rice.pastry.socket) i ens permet comunicar dos nodes a partir del Internet Protocol (IP). La classe Socket utilitza el protocol TCP per enviar tots els missatges excepte els missatges de “liveness” per als quals utilitza el protocol UDP. Per poder inicialitzar la capa de transport Socket, i amb aquesta el node, necessitem un seguit de variables que ens facilita el software de FreePastry. Aquestes són: • PastryNode  És el nom que rep l’objecte encarregat de mantenir totes les funcions del node en una xarxa Pastry. Gestiona la taula de ruta, leafset i l'endpoint per on s’envien els missatges. • NodeId    Aquesta variable és la que emmagatzema l’identificador del node a la xarxa, aquest identificador ha de ser únic en l’anell de Pastry. • NodeIdFactory    La interfície NodeIdFactory és l’encarregada de generar un nodeId localment pel node. L’assignació de NodeIds locals pot ser crític ja que no hi pot haver nodeIds repetits. A fi de salvar aquest problema, normalment en les xarxes Pastry hi ha una Autoritat Certificadora central que s’encarrega de gestionar l’assignació de nodeIds. En el nostre cas, l’assignació de nodeIds la realitzarem localment a partir de la interfície RandomNodeIdFactory. 18 Integració d’un Proxy de serveis web en una xarxa P2P DHT • PastryNodeFactory  És la interfície encarregada d’inicialitzar l’objecte PastryNode. Amb la inicialització del PastryNode també s’inicialitza la taula de veïnari (leafset) i la taula d'enrutament. • NodeHandle  El NodeHandle és una variable que guarda una “referència” a un node Pastry. En la nostra aplicació la referència serà l’adreça IP i el port per on està escoltant el node al que ens volem connectar. • Bootstrap Node  El bootstrap node és una variable tipus NodeHandle. En aquesta variable emmagatzemem la referència a un node que ja pertany a la xarxa Pastry per poder connectar quan iniciem el node. En el nostre cas, com ja hem esmentat abans, la informació necessària per inicialitzar el node a la xarxa Pastry es transmet com a arguments al fer la crida al mètode main. El procediment per inicialitzar un node en una xarxa Pastry gairebé sempre és el mateix, I en el cas de la nostra aplicació es troba en la funció connect de la clase MyMain tal com podem observar a la figura 3.4: public void connect(int bindp, String bootaddresss, int bootp){ try { env = new Environment(); bindport = bindp; bootaddr = InetAddress.getByName(bootaddresss); bootport = bootp; bootaddress = new InetSocketAddress(bootaddr, bootp); //Creem el NodeId nidFactory = new RandomNodeIdFactory(env); //18onstruïm la PastryNodeFactory per inicialitzar el node factory = new SocketPastryNodeFactory(nidFactory, bindport, env); //Funcio que retorna Null si no contacta amb el bootstrap node bootHandle=((SocketPastryNodeFactory)factory). GetNodeHandle( bootaddress); // En aquesta sentencia 18onstruïm el node i l’inicialitzem node = factory.newNode(bootHandle); // Amb aquesta sentencia esperem que el node acabi d’inicialirzar //les taules de ruta i leafset while (!node.isReady()){ Thread.sleep(100); System.out.println(“\nFinished creating new node “ + node); //Quant el NodePastry esta creat inicialitzem l’objecte MyApp app = new MyApp(node); } catch (Exception e){ System.out.println(e.toString()); } } Figura 3.4 Codificació necessària per inicialitzar un node i connectar-lo a una xarxa Pastry Capítol 3. Implementació de l’aplicació 19 3.1.1.3 La classe MyApp La classe MyApp, com ja hem comentat anteriorment, és una implementació de la interface Applicaction del sofware de Pastry. Aquesta interface és facilitada a fi de poder implementar noves aplicacions sobre el nodePastry. Tal com podem observar en la figura 3.5 l’objecte MyApp consta de dos objectes WebServiceP2P anomenats wsLocal i wsPublished, un Endpoint, una variable ListId (s’emmagatzema el id on esta publicada la llista de WebServices que hi ha a la xarxa), un vector amb la llista de WebServices publicats a la xarxa (en aquest vector s’emmagatzema el nom i la descripció del WebService) i un conjunt de funcions que permeten publicació, cerca i execució de WebServices. La classe WebServiceP2P ve implementada amb l'anterior projecte; aquesta consta d’un objecte WSDesc i un objecte WebServiceP2P. En l’objecte WSDesc s’emmagatzemen les dades referents a un WebService. Aquest objecte està format per 4 variables del tipus String en les que s’emmagatzema el nom del WebService, una breu descripció sobre aquest, l’adreça web (url) del servidor Web on es troba allotjat i l’adreça URL en la que es troba l’arxiu descriptor .wsdl del WebService. L’objecte WebServiceP2P s’encarrega de gestionar un Vector de WSDesc. Per tant, en els objectes wsLocal i wsPublished s’emmagatzema la informació dels WebServices que un node ha generat i ha publicat respectivament. Figura 3.5: Estructura de l’objecte MyApp 20 Integració d’un Proxy de serveis web en una xarxa P2P DHT Les funcions que implementa la classe MyApp són: isReady  És un mètode públic del tipus boolean. Aquest mètode porta el sincronisme entre l’objecte MyMain i l’objecte MyApp. En l’objecte MyMain es recullen totes les dades per a poder executar les funcions dels nodes, aquestes però, van programades en l’objecte MyApp. Per tant, aquesta funció s’encarrega d’avisar al objecte MyMain que l’acció ha conclòs. publishWebService    És un mètode públic del tipus void. Amb la crida a aquesta funció s’ha de passar com a paràmetres la informació del WebService a publicar. Aquesta informació s’emmagatzema en l’objecte wsLocal i es crea el missatge XML que s’envia a la xarxa. listWebService    És un mètode públic del tipus void. Aquest mètode retorna al node una llista amb tots els WebServices que hi ha publicats a la xarxa. El node que sol·licita la llista, envia un missatge XML al node que està gestionant la variable WSList. executeWebService    És un mètode públic del tipus void. Aquest mètode, a partir del nom d’un WebService, envia al node que el té publicat la petició de la informació necessària per a executar el WebService. Un cop té la informació requerida fa la crida al mètode getObjectsWsdl. search    És un mètode públic del tipus void. Aquest mètode s’usa per cercar WebServices publicats en una xarxa P2P. El node que sol·licita la cerca d’un WebService, envia un missatge XML amb el nom del WebService al node que està gestionant la variable WSList. getObjectsWsdl    És un mètode private del tipus void. Aquest mètode s’usa per executar un WebService a partir del seu arxiu .wsdl. En aquest mètode s’usa un software que es troba implementat en la llibreria com.tfc.wsdl a fi de poder parcejar i usar la informació de l’arxiu .wsdl per a poder interactuar amb el WebService deliver    És un mètode del tipus void. Aquest mètode és heretat de la interface Application. Aquest mètode es posa en funcionament cada cop que arriba un missatge al nodePastry 3.1.1.4 MyMsgXML la classe MyMsgXML és una implementació de la classe Message que ens facilita el software de FreePastry; aquesta interfice s’usa per a definir els missatges que s’intercanviaran els nodes. Aquesta classe crea un objecte que contenen dues variables del tipus Id on emmagatzemen el Id del node origen del missatge i l’Id del node receptor del missatge i una variable tipus String anomenada XML que conté el missatge que es volen intercanviar. Capítol 3. Implementació de l’aplicació 21 Com ja hem comentat abans, els missatges que s’intercanvien els nodes estan en format XML, per tant, la classe MyMsgXML conté un seguit de funcions de tipus String que retornen un missatge XML construït amb tots els paràmetres de la capçalera de la funció. public class MyMsgXML implements Message { Id from, to; String xml; public static String getPublishXML(String name,String url,String wsdl,String description) { return "<message>" + "<type>publish</type>" + "<name>"+name+"</name>" + "<url>"+url+"</url>" + "<wsdl>"+wsdl+"</wsdl>" + "<description>"+description+"</description>" + "</message>"; } } Figura 3.6 Captura de la codificació de la classe MyMsgXML, es pot observar les variables i una funció generadora d’un missatge XML 3.1.2 Publicació d’un Servei Web En aquest apartat comentarem l’intercanvi de missatges i accions que es duen a terme per a poder publicar un WebService. Aquest segueix el següent esquema: . Figura 3.7 Esquema de la publicació d’un WebService En el primer pas, el node que vol publicar el WebService, genera un objecte del tipus WSDesc amb tota la informació necessària per a publicar el WebService tal com podem observar en la figura 3.8. Un cop generat l’objecte 28 Integració d’un Proxy de serveis web en una xarxa P2P DHT En el segon pas, el node que rep el missatge getPublishProxyXML, recupera la informació del Proxy a publicar i l’emmagatzema en un objecte WSProxy. Seguidament, emmagatzema la informació en el vector ProxyList de l’objecte MyApp. Un cop emmagatzemada la informació del Proxy publicat, el node envia un missatge XML (getPublishResponseProxyXML) al node que li ha enviat la petició de publicació indicant-li que ha estat efectuada amb èxit. Finalment, en el tercer pas, el node que ha guardat la informació del Proxy, envia un missatge XML (copyProxyXML) amb una còpia de la informació publicada a tota la seva LeafSet. Aquesta acció es duu a terme per a oferir a la xarxa robustesa enfront de caigudes ja que d’aquesta manera si el node que conté la llista general de Proxys publicats (ProxyList) cau, no es perd la informació, ja que el seu node adjacent passarà a gestionar el seu espai de claus i per tant la ProxyList que té com a backup. 3.2.3 Cerca d’un Servei Web En aquest apartat estudiarem l’intercanvi de missatges que es produeixen quant un node vol buscar un WebService; aquest apartat ha estat modificat respecte al projecte anterior per a que si no es troba el WebService a la xarxa, el node que el busca, sol·liciti la informació necessària per a poder-se connectar al Proxy i sol·licitar-li la cerca del WebService a les xarxes que està connectat. La cerca de WebServices es realitza segons el següent esquema: Figura3.16: Esquema de la cerca d’un WebService que no es troba a la xarxa Capítol 3. Implementació de l’aplicació 29 Tal com podem observar en la Figura 3.16, els dos primers passos en la cerca del WebService no han estat modificats del projecte inicial. En el primer pas, el node envia el missatge XML (getSearchXML) al node que està gestionant la llista general de WebServices publicats a la xarxa (WSList). En el segon pas, el node que gestiona la llista general de WebServices publicats a la xarxa retorna al node que l’ha sol·licitat un missatge XML (getSearch2XML) inidant-li que no ha trobat el WebService sol.licitat. Al rebre el missatge de que el WebService no s’ha trobat, el node que cercava el WebService, genera un missatge XML (getSearchProxyXML) amb destí, el node que gestiona la part de la taula DHT que conté el ID listProxy, aquesta entrada de la taula DHT gestiona la llista de Proxys (ProxyList) tal com podem observar al pas 3. En el pas 4, el node que gestiona el vector ProxyList al rebre el missatge de cerca, retorna al node Pastry que ha realitzat la consulta la llista de Proxys publicats en la xarxa. Per a enviar la llista de Proxys al node que l’ha sol·licitat, el node que la conté, envia un missatge XML (SearchProxyResponse) per a cada entrada de Proxy que tingui al vector ProxyList. Com ja hem comentat anteriorment, el vector ProxyList és un vector d’objectes WSProxy; aquests objectes consten de tres Strings on s’emmagatzema la informació necessària per establir connexió amb el Proxy. Figura 3.17: Esquema de la connexió d’un node al Proxy per a cercar un WebService en altres xarxes 30 Integració d’un Proxy de serveis web en una xarxa P2P DHT Un cop el node que està buscant el WebService ha obtingut la informació necessària per poder establir connexió amb el node que fa de Proxy, crea un thread que conté un node. El thread estableix connexió amb el Proxy a partir dels paràmetres que ha obtingut el node de la xarxa, tal com podem observar a la Figura 3.17 en el pas 5. En el pas 6, quant la connexió amb el Proxy ha estat establerta, el node que busca el WebService envia un missatge XML (ConnectToProxy) a través del Thread. Aquest missatge conté el nom del WebService a buscar. En el moment que el Proxy rep el missatge de cerca amb el nom del WebService a buscar, envia una petició de cerca mitjançant un missatge XML (getSearchProxyXML) a través de totes les xarxes a les que està connectat tal com ens mostra el pas 7 de la Figura 3.17. Per a poder enviar la petició a totes les xarxes a les que està connectat el Proxy, l’aplicació recorre tot el vector Redes. Cal recordar que cada espai del vector Redes es un objecte MyMain encarregat de gestionar un node, cada objecte del vector Redes esta connectat a una xarxa. El missatge de cerca que envia el Proxy a totes les xarxes porta com a destinatari, en totes elles, el node que està gestionant la llista general de WebServices publicats en aquella xarxa, la WSList. El node que la gestiona, al rebre el missatge XML de cerca del WebService, en fa una en tot el vector WSList del pattern donat pel missatge. Tant si el WebService està publicat en aquella xarxa com si no, el node que gestiona la WSList de la xarxa envia un missatge XML (getSearchProxy2XML) al Proxy indicant el nom i la descripció del WebService que s’està cercant tal com mostra el pas 8 de la Figura 3.18. Si el WebService no ha estat trobat en la xarxa el missatge XML (getSearchProxy2XML) que s’envia al Proxy porta els camps de nom i descripció amb el valor “none” Figura 3.18: Esquema de l’intercanvi de Missatges entre el Proxy i els nodes de les Xarxes a les que està connectat per a cercar un WebService Un cop el Proxy ha rebut totes les respostes de cerca de les Xarxes a les que està connectat, avalua a quines xarxes s’ha trobat el WebService i a quines no, tal com podem observar al pas 9 de la Figura 3.19, el Proxy realitza Capítol 3. Implementació de l’aplicació 31 dos accions diferents en funció de si el WebService ha estat trobat a la xarxa o no: • Per a les xarxes on no s’ha trobat el WebService, el Proxy envia un missatge XML (WSResponceXML) al Thread del node que originalment estava buscant el WebService indicant-li en el camp del nom, del missatge XML, el valor none. • Per a les xarxes on s’ha trobat el WebService, el Proxy envia un missatge XML (getExecuteProxy) al node de la xarxa que ha publicat el WebService sol·licitant-li l’objecte WSDesc que conté la informació necessària per executar el WebService. Figura 3.19: Esquema de l’intercanvi de Missatges entre el Proxy i els nodes de les Xarxes a les que esta connectat per a cercar un WebService El node que té el WebService que s’està cercant, al rebre el missatge XML (getExecuteProxy), busca en la seva WSPublished a fi de trobar el WSDesc del WebService sol·licitat. Un cop trobat, el node que té el WebService publicat envia un missatge XML (getExecuteProxy2XML) al Proxy amb la informació necessària per a poder executar el WebService tal com podem observar en el pas 10 d la Figura3.20. Un cop el Proxy rep els missatges XML (getExecuteProxy2XML) transmet la informació al Thread del node que originalment estava buscant el WebService a través d’un missatge XML (WSResponceXML). 32 Integració d’un Proxy de serveis web en una xarxa P2P DHT Figura 3.20: Esquema de les accions que realitza el Proxy en base als missatges de resposta de les Xarxes a les que està connectat Cal destacar que el Thread del node porta un control de les xarxes a les que el Proxy està connectat ja que quant estableixen connexió el Thread i el Proxy aquest li serveix un missatge XML (inforedes) indicant-li a quantes xarxes està connectat. Això ens permet que el node que cerca un WebService a través del Proxy esperi a rebre els missatges de resposta de totes les xarxes per a decidir quin WebService vol executar. En la implementació que hem fet nosaltres de la xarxa, el node executa el primer WebService que es troba, tanmateix es podria haver implementat alguna política a l’hora d’escollir el WebService que s’executa en funció de la proximitat mètrica, temps de resposta del servidor, cost de connexió amb el Servidor... Un cop obtinguts tots els missatges XML de resposta, un per a cada xarxa a la que el Proxy està connectat, el node que cercava el WebService destrueix el node que tenia creat al thread i invoca el mètode getObjectsWsdl, amb la informació obtinguda de la xarxa, a fi d'executar el WebService buscat. Capítol 4. Proves de l’aplicació 33 CAPITOL 4. PROVES DE L’APLICACIÓ Per tal de comprovar si les variacions que hem realitzat al codi d’un node Pastry de l’anterior TFC per a que realitzi les funcions de Proxy han estat correctes, hem implementat una xarxa de prova amb dos ordinadors. En aquests dos ordinadors hem iniciat dues xarxes Pastry i un Proxy que fa de punt d’interconnexió de les dues xarxes. Tal com podem observar en la figura 4.1, la xarxa es composa d’un terminal A (amb adreça IP 192.168.1.2), on estan iniciades les dues xarxes Pastry. Aquestes xarxes consisteixen en un únic node cadascuna. La xarxa 1 té com a nodeHandle 192.168.1.2:53006 i la xarxa 2 porta com a nodeHandle 192.168.1.2:53006. En el segon terminal hem iniciat el codi del Proxy i un analitzador de Protocols per a veure l’intercanvi de paquets que es produeixen. L’estructura de la xarxa de proves és la següent: Figura 4.1: Esquema de la xarxa en la que es realitzaran les proves de l’aplicació Un cop iniciada les dues Xarxes i el node que farà de Proxy entre les dues xarxes, per a cada xarxa, hem publicat un WebService. Per a la xarxa 1 hem usat el WebService CalculadoraWS, aquest WebService venia implementat amb l’anterior TFC. Les dades de connexió són: Nom del WebService: CalculadoraWS Url del WebService: http://localhost:8080/axis/services/CalculadoraWS Url del arxiu WSDL: http://localhost:8080/axis/services/CalculadoraWS?wsdl Descripció: Programa que emula una calculadora Figura 4.2: Captura de l’aspecte del menú de publicació del node de la xarxa1 34 Integració d’un Proxy de serveis web en una xarxa P2P DHT Per a la xarxa 2 hem usat el WebService BotigaWeb, aquest WebService l’hem implementat a partir del tutorial que ens facilita la pagina web de Axis. Les dades de connexió son: Nom del WebService: BotigaWeb Url del WebService: http://localhost:8080/axis/services/BotigaWeb Url del arxiu WSDL: http://localhost:8080/axis/services/BotigaWeb?wsdl Descripció: Botiga virtual Figura 4.3: Captura de l’aspecte del menú de publicació del node de la xarxa2 Un cop inicialitzades les dues xarxes i el Proxy, i publicats els WebServices en les seves respectives xarxes. El que hem realitzat és una busqueda dels WebServices publicats per a veure que retornava el programa. Cal recordar que al terminal que fa de Proxy hem iniciat un analitzador de Protocols a fi de poder observar l’intercanvi de paquets que es produïen entre els nodes. Els resultats que hem obtingut han estat satisfactoris i van detallats a continuació: Per a una cerca d’un WebService que es troba a la xarxa, un node retorna la següent captura: Figura 4.4: Captura del resultat d’una cerca d’un WebService que es troba a la xarxa del node Capítol 4. Proves de l’aplicació 35 Per a una cerca d’un WebService que no es troba a la xarxa on es cerca, el node que cerca el WebService retorna la següent captura: Figura 4.5: Captura del resultat d’una cerca d’un WebService que no es troba a la xarxa del node que el cerca Per a una cerca d’un WebService que no es troba en cap xarxa a les que pertany el Proxy, el node que cerca el WebService retorna la següent captura: Figura 4.6: Captura del resultat de la cerca d’un WebService que no es troba en cap xarxa 36 Integració d’un Proxy de serveis web en una xarxa P2P DHT Un cop realitzades totes les proves amb l’aplicació Proxy, hem revisat els paquets que hem capturat des del node que fa de Proxy. Hem pogut observar que realment els paquets que s’envien entre els nodes són els descrits en el MyMsgXML. A continuació, presentem les captures d’alguns dels paquets vistos en el analitzador de protocols. Figura 4.7: Captura feta des de l’analitzador de protocols d’un missatge de publicació del Proxy en la xarxa 1 Figura 4.8: Captura feta des de l’analitzador de protocols d’un missatge de Publicació d’un WebService en la xarxa 1 Capítol 4. Proves de l’aplicació 37 Figura 4.9: Captura feta des de l’analitzador de protocols d’un missatge de cerca d’un WebService que no es troba a la xarxa 1 Figura 4.9: Captura feta des de l’analitzador de protocols d’un missatge de cerca d’un WebService que no es troba a la xarxa 1