Zerankwa plataforma de desarrollo colaborativo con eclipse

Texto completo

(1)ISC-2003-2-32. ZERANKWA PLATAFORMA DE DESARROLLO COLABORATIVO CON ECLIPSE. DIEGO ANDRÉS RAMÍREZ ARAGÓN. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE SISTEMAS Y COMPUTACIÓN BOGOTÁ, ENERO DE 2004 1.

(2) ISC-2003-2-32. ZERANKWA PLATAFORMA DE DESARROLLO COLABORATIVO CON ECLIPSE. DIEGO ANDRÉS RAMÍREZ ARAGÓN. Tesis de grado para optar al título de Ingeniero de Sistemas y Computación. Asesor Rubby Casallas Doctora en Informática. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE SISTEMAS Y COMPUTACIÓN BOGOTÁ, ENERO DE 2004 2.

(3) ISC-2003-2-32. Tabla de Contenido. I. Introducción.........................................................................................................................6 III. Marco Teórico.................................................................................................................. 8 III.1. Global Software Development................................................................................. 8 III.2. Tecnologías de Comunicación................................................................................10 III.2.1. Cliente/Servidor.............................................................................................. 11 III.2.1.1. WebServices............................................................................................ 11 III.2.1.2. WebDAV................................................................................................. 12 III.2.2. Sistemas Distribuidos..................................................................................... 14 III.2.2.1. JavaGroups.............................................................................................. 14 III.2.2.2. JXTA........................................................................................................16 III.3. Ambientes de Desarrollo........................................................................................ 18 III.3.1. Eclipse............................................................................................................. 18 III.3.1.1. Arquitectura de Eclipse........................................................................... 22 IV. Requerimientos de Zerankwa......................................................................................... 26 IV.1. Requerimientos de Sistemas Distribuidos............................................................. 26 IV.2. Requerimientos de la plataforma colaborativa...................................................... 26 V. Diseño e Implementación de Zerankwa.......................................................................... 30 V.1. Arquitectura de Zerankwa........................................................................................ 30 V.2. Implementación de Zerankwa.................................................................................. 32 V.2.1. co.edu.uniandes.zerankwa.gui.......................................................................... 33 V.2.2. co.edu.uniandes.zerankwa................................................................................ 35 VI. Evaluación...................................................................................................................... 38 VI.1. Eclipse y SWT........................................................................................................ 38 VI.2. JXTA....................................................................................................................... 39 VII. Conclusiones y trabajos futuros....................................................................................40 VIII. Bibliografía.................................................................................................................. 42 IX. Anexo 1: Common Public License v 1.0........................................................................45 X. Anexo 2: Imágenes de la Interfaz gráfica........................................................................52 XI. Anexo 3: Diagramas de Clases: co.edu.uniandes.zeranwka.gui.................................... 56 XII. Anexo 4: Diagramas de Clases: co.uniandes.zerankwa................................................57. 3.

(4) ISC-2003-2-32. Lista de Figuras. Figura II.1Arquitecutra JavaGroups[2]................................................................................ 15 Figura II.2 Tipos de Pipes en JXTA[3]................................................................................ 17 Figura II.3 Arquitectura de JXTA[3]....................................................................................18 Figura II.4 Arquitectura Eclipse[1]...................................................................................... 23 Figura II.5Arquitectura del Workbench............................................................................... 25 Figura IV.1 Arquitectura Zerankwa..................................................................................... 30 Figura IX.1Vista de Grupos y Usuarios............................................................................... 52 Figura IX.2Vista de Mensajes.............................................................................................. 53 Figura IX.3Página de Preferencias....................................................................................... 54 Figura IX.4Página de Propiedades del proyecto.................................................................. 55 Figura X.1 Diagrama de Paquetes Zerankwa UI.................................................................. 56 Figura XI.1 Diagrama de Clases Zerankwa Core.................................................................57 Figura XI.2 Diagrama de Clases del Paquete jxta.jaas........................................................ 58. 4.

(5) ISC-2003-2-32. A mis dos familias la de sangre y la de espíritu que me han apoyado en todo momento. 5.

(6) ISC-2003-2-32. I. Introducción En los últimos años el desarrollo de software ha experimentado muchos cambios, uno de ellos es la globalización de los grupos de desarrollo o Global Software Development. Este fenómeno ha venido creando nuevos retos dentro del campo de la ingeniería de software debido a que cada vez se hace más importante encontrar vías para minimizar los problemas relacionados con diferencias temporales, geográficas y culturales en esta nueva manera de hacer software al interior de los grupos de trabajo. Estas dificultades se presentan en todas las fases del desarrollo (desde la etapa de diseño hasta el proceso de depuración y pruebas) y su causa principal es la falta de comunicación entre los distintos miembros del equipo. Estas fallas se hacen particularmente evidentes durante la implementación, donde problemas como dudas acerca de detalles de codificación o dificultades en la configuración del ambiente de trabajo, puden durar horas e incluso días en solucionarse dependiendo de la distribución de los miembros del grupo de trabajo. Tradicionalmente la solución de estos problemas se lleva a cabo a través de sistemas de mensajería instantánea o. por medio del correo electrónico, pero es claro que estas. aplicaciones no son suficientes ya que no brindan los elementos sincrónicos necesarios para la solución a estos y otros problemas que se presentan con regularidad durante las diferentes etapas del desarrollo. Teniendo en cuenta esta problemática, se ve la necesidad de crear una plataforma de desarrollo que permita llevar a cabo las tareas de programar, probar y depurar aplicaciones de manera colaborativa y sincrónica, compartiendo archivos de código fuente y haciendo modificaciones simultáneas sobre estos. La construcción de dicha plataforma puede tomar como punto de partida alguno de los IDE's disponibles en el mercado, pues la mayoría de ellos ya tienen implementadas varias de estas tareas (asistencia de código, ejecución, depuración) y poseen mecanismos de extensión mediante. 6.

(7) ISC-2003-2-32 los cuales pueden ser construidas herramientas con las características de sincronismo y colaboración de las que carecen actualmente. El propósito de esta tesis, Zerankwa1 (Plataforma de Desarrollo Colaborativo con Eclipse), es desarrollar un plug-in de Eclipse©[1] que brinde a los desarrolladores la posibilidad de compartir de manera sincrónica los recursos de un proyecto de software dentro del IDE. Estos recursos pueden ser código Java o archivos de configuración que pueden ser editados de manera simultánea por varios miembros del grupo de desarrollo. Del mismo modo, permite la ejecución remota de aplicaciones, pruebas, el envío y recepción de mensajes a través de un servicio de mensajería instantánea y facilidades para la integración con otras herramientas de la organización que brinden la funcionalidad de planeación y seguimiento del proyecto. Este documento esta organizado de la siguiente manera: En el capítulo 2 se presenta un marco teórico en el que se exponen generalidades acerca del GSD (Global Software Development) y el estado del arte de varias tecnologías de comunicación que pueden ser utilizadas para la implementación de sistemas de desarrollo colaborativo de software. En los capítulos 3 y 4 se definien los requerimientos y el diseño del plug-in. Posteriormente, en el capítulo 5 se describen los detalles de la implementación. Finalmente se presentan las conclusiones y algunas proyecciones de trabajos futuros.. 1. ZeRankwa: Palabra usada por los indígenas de la Sierra Nevada de Santa Marta cuyo significado es: “El estado donde puedes hablar con todo”. 7.

(8) ISC-2003-2-32. III. Marco Teórico En este capítulo se muestra el estado del arte de los temas alrededor de los cuales está desarrollada esta tesis. Estos temas son: el Global Software Development (desarrollo de software distribuido o global), las distintas tecnologías de comunicación existentes en la actualidad para la implementación de sistemas con algún grado de distribución y la descripción de la arquitectura de Eclipse.. III.1. Global Software Development En la actualidad una de las tendencias más sobresalientes en el área del desarrollo de software es la creación de grupos distribuidos geográficamente. Varios autores [11][13] [14][16] están de acuerdo en que este giro que ha redefinido la manera de establecer los grupos de trabajo se debe principalmente al rápido crecimiento que ha tenido la industria en los últimos años y que les ha permitido a las empresas llevar a sus equipos más allá de las fronteras de sus países para volverse más competitivas a nivel global; y a los avances hechos en la infraestructura de las telecomunicaciones que hacen más fácil la comunicación entre sitios geográficamente distantes. Algunas de las ventajas que presenta este esquema sobre la manera tradicional de establecer los grupos de desarrollo son[11][16]: ✔. Enriquecimiento de los grupos con talento especializado: Los equipos de desarrollo tradicionales muchas veces se ven limitados por la. experiencia y. habilidades de sus miembros y la disponibilidad de la mano de obra local. Los grupos distribuidos superan esta limitación por la búsqueda de personas con talentos no disponibles localmente y que pueden trabajar desde sus lugares de origen. ✔. Estar más cerca del cliente: La internacionalización de los productos requiere de ajustes a la medida que pueden llevarse de manera más rápida teniendo grupos de desarrollo en el mismo lugar(país) donde se encuentra el cliente. 8.

(9) ISC-2003-2-32 ✔. Días de 24 horas: En grupos altamente distribuidos es posible crear la ilusión de días de trabajo de 24 horas, p.e. Un desarrollador en Colombia que termina su turno a las 6 es “relevado” por otro en India que esta iniciando su labor de trabajo del día siguiente.. ✔. Reducción en los costos de personal: Esto es particularmente cierto para grandes empresas de Estados Unidos o Europa, que pueden encontrar mano de obra barata en otras regiones del mundo como Indochina y Lationamerica.. Por otra parte, este nuevo esquema también trae consigo nuevas dificultades[11][16]: ✗. Pérdida de información: Las distancias entre los sitios de trabajo dificultan los encuentros informales, que son una de las mayores fuentes de conocimiento al interior de los grupos de desarrollo de software. Paralelo a esto, la falta de encuentros persona-persona dificulta la creación de lazos de confianza que faciliten la comunicación de los miembros del grupo, pues a pesar de que existan herramientas como los sistemas de mensajeria instantánea, muchas personas encuentran difícil comunicarse con personas que no conocen[12].. ✗. Problemas de coordinación y manejo del conocimiento: En los grupos distribuidos, la división y coordinación del trabajo se tornan aspectos críticos, pues la existencia de interdependencias generan demoras y bajas en el desempeño del grupo. Además se hace importante tener un control de las tareas y errores para poder identificar efectivamente quién es el encargado de solucionar un problema.. ✗. Diferencias culturales: Las diferencias culturales y de lenguaje existentes entre países e incluso dentro de regiones de un mismo país, pueden crear malentendidos que dificultan la evolución del proyecto.. ✗. Diferencias temporales: Las diferencias temporales crean dificultades en el establecimiento de reuniones sincrónicas ya sea a través de video conferencia u otros medios electrónicos, lo que entorpece la evolución de ciertas tareas del proceso de desarrollo. Por ejemplo, en la etapa de diseño son muy importantes las discusiones y acuerdos hechos sobre la arquitectura del proyecto. 9.

(10) ISC-2003-2-32 ✗. Diferencias tecnológicas: La existencia de distintas configuraciones de hardware y software, y la no estandarización de los protocolos de comunicación, hacen posible que surjan dificultades cuando se integran las distintas partes del sistema.. ✗. Problemas de seguridad: Los grupos de trabajo distribuidos requieren la definición de políticas de seguridad y control más estrictas para el acceso a los repositorios y sistemas de control de proyecto de la organización.. La efectividad de este tipo de grupo de desarrollo se puede ver claramente en varios de los proyectos de código abierto como Linux, Apache, Posgresql, Eclipse, Mozilla entre otros, que están compuestos por desarrolladores que trabajan voluntariamente en ellos y se distribuyen en varios países alrededor del mundo. Cabe aclarar que teniendo en cuenta las dificultades anteriormente mencionadas, el desempeño de estos grupos aún no es el óptimo, lo que hace necesario el desarrollo de herramientas más efectivas para la comunicación y coordinación de los distintos miembros del equipo. Actualmente existen varias iniciativas como D-UML[18], una herramienta que permite realizar diagramas de clases de manera distribuida, Palantir[17], una aplicación que permite conocer los cambios y el impacto de estos sobre un proyecto de software y MILOS[11], un sistema que provee funcionalidades de workflow y control de errores que ayudan a minimizar el impacto de los problemas mencionados al interior de los grupos de trabajo distribuido. Aún hay mucho por investigar en este campo, siendo necesario establecer cuáles son las metodologías más adecuadas para estos grupos de trabajo, cuáles son las tecnologías y arquitecturas mas convenientes para la implementación de las herramientas de apoyo, entre otros.. III.2. Tecnologías de Comunicación En la actualidad existe una gran variedad de tecnologías que permiten la comunicación entre aplicaciones distribuidas. Esta diversidad dificulta la tarea de seleccionar en un 10.

(11) ISC-2003-2-32 momento dado cuáles son las más adecuadas para un proyecto de software en particular. Entre estas tecnologías están los Web Services, WebDAV, JavaGroups y JXTA, que a continuación se explican en detalle.. III.2.1. Cliente/Servidor Las arquitecturas cliente/servidor y las ahora llamadas arquitecturas multinivel son la base de la mayoría de los sistemas distribuidos que existen en la actualidad, los WebServices y WebDAV son algunas de las tecnologías que soportan estos sistemas. A continuación una descripción de cada una. III.2.1.1. WebServices Los Web Services son aplicaciones que pueden ser accedidas mediante un URL tanto en Internet como dentro de una Intranet. Su propósito principal es facilitar la integración de diversas aplicaciones tanto dentro de la organización como fuera de ella, pueden operar de una manera bajamente acoplada, es decir, sus componentes pueden ser cambiados fácilmente en tiempo de ejecución. Gracias a que los Web Services se describen a si mismos mediante el archivo WDSL(Web Services Description Language), y son publicados dentro de servidores de registro UDDI (Universal Discovery, Description and Integration), facilitan la tarea de encontrar, usar e integrar servicios. Gracias a los Web Services es posible hablar en este momento de Arquitecturas SOA (Service-Oriented Architectures), en las que el desarrollo de una aplicación ya no está dado únicamente en la necesidad de solucionar un conjunto de requerimientos funcionales; ahora también se tiene que pensar en la manera en que dicha aplicación puede brindar servicios tanto dentro. como fuera de los límites de la organización. Los Web Services usan para su comunicación un protocolo basado en XML llamado SOAP (Simple Object Access Protocol), que define de manera estándar el esquema en que se hacen los requerimientos a uno de estos servicios y la forma en que estos deben retornar los mensajes. De esta manera se logra desacoplar los lenguajes de 11.

(12) ISC-2003-2-32 implementación y comunicación, facilitando la tarea de integrar aplicaciones desarrolladas en diferentes plataformas y lenguajes. Debido a que existe un amplia gama de aplicaciones que no necesitan el nivel de detalle que provee la especificación SOAP, posteriormente se creó un subconjunto de la misma llamada XML-RPC, que hace más fácil la implementación de Web Services de pequeña escala.. III.2.1.2. WebDAV WebDAV (Web-based Distributed Authoring and Versioning) [5] es una extensión del protocolo HTTP desarrollada alrededor de 1996 por la IETF2 y que es especificado en el RFC2518[6], que pretende hacer de la Web un medio escribible, permitiendo que varias aplicaciones puedan interoperar a través de HTTP mediante el intercambio de diferentes tipos de recursos, que no necesariamente son archivos planos como HTML y XML. WebDAV define un conjunto de nuevos encabezados y métodos que facilitan la navegación y el mantenimiento de sitios Web, estos nuevos métodos permiten la manipulación de Properties (Méta-información sobre los recursos almacenados en el servidor) y Collections (Conjuntos de recursos [Directorios]), controlar el acceso a recursos que se encuentren en uso y además heredar todas las ventajas de la estructura HTTP/HTTPS, como la autenticación, la encripción y la navegación a través de Firewalls y Proxies. A diferencia de los métodos tradicionales de HTTP, los métodos de WebDAV poseen un cuerpo XML, esto para darle flexibilidad al protocolo y poder hacer varias operaciones con un solo requerimiento. Los nuevos encabezados y métodos especificados por WebDAV serán explicados brevemente a continuación: Encabezados: ➔. Dav: Indica que el recurso soporta el esquema DAV. ➔. Depth: Este encabezado se usa cuando se desea hacer operaciones sobre colecciones de recursos (COPY, MOVE), y especifica el nivel de profundidad. 2. Internet Engineering Task Force. 12.

(13) ISC-2003-2-32 con que se quiere trabajar, solo el recurso (Depth: 0), solo sus hijos inmediatos (Depth: 1), o el recurso y todos sus hijos, nietos, etc (Depth: infinity) ➔. Destination: Especifica el URI de destino para los métodos COPY y MOVE.. ➔. If: Permite especificar condiciones sobre el requerimiento, especialmente en conjunto con el encabezado Lock-token, para acceder a recursos protegidos con un candado.. ➔. Lock-token: Especifica el candado que debe ser eliminado por el método UNLOCK, y como respuesta al método LOCK, especifica el identificador del candado creado.. ➔. Overwrite: Especifica la acción que se debería tomar en el caso que alguno de los recuros especificados por una operación MOVE o COPY exista previamente en el servidor.. ➔. Status: Especifica el resultado de una operación.. ➔. Timeout: Permite especificar el tiempo máximo de un candado si este no es renovado, esto para evitar el bloqueo de recursos en el caso que se olvide eliminar un candado.. Métodos: ➔. PROPFIND: Permite obtener información sobre los recursos.. ➔. PROPPATCH: Permite modificar las propiedades de los recursos.. ➔. COPY: Permite copiar recursos dentro del servidor.. ➔. MOVE: Permite mover recursos de un lugar a otro dentro del servidor.. ➔. DELETE: Permite eliminar recursos.. ➔. LOCK/UNLOCK: Permiten crear y eliminar candados sobre los recursos para evitar problemas de sobreescritura dentro del servidor Web.. 13.

(14) ISC-2003-2-32 ➔. MKCOL: Permite crear un directorio dentro del servidor.. Paralelo a WebDAV, la IETF ha estado desarrollando otras extensiones a HTTP como DeltaV (Manejo de versiones), ACL3 (Gestión de acceso a los recursos) y DASL4 (Mecanismo de Búsqueda), que hacen de WebDAV una especificación muy robusta que se puede usar en cualquier contexto. La aceptación que ha tenido WebDAV en la industria es muy amplia, lo que se refleja en la gran cantidad de aplicaciones que actualmente implementan esta especificación, como Microsoft Office (por medio de sus Carpetas Web), Adobe Acrobat 5, Mac OS X, Macromedia Dreamweaver, Apache Tomcat, Apache httpd, entre otros.. III.2.2. Sistemas Distribuidos La creación de aplicaciones 100% distribuidas ha sido apoyada desde sus inicios por varias especificaciones como CORBA, RMI, RPC, entre otras. A continuación se mostrarán dos de las más recientes tecnologías en este campo, JavaGroups y JXTA que son dos nuevas especificaciones basadas en el lenguaje de programación Java. III.2.2.1. JavaGroups JavaGroups[2] es un toolkit para diseñar aplicaciones que necesitan un medio de comunicación confiable. Los procesos que se comuniquen por medio de JavaGroups pueden crear grupos, enviar y recibir mensajes y ser notificados de cuándo un miembro entra o sale. Para hacer uso de JavaGroups, la aplicación puede usar directamente el API del Canal o utilizar los diferentes Building Blocks que provee el framework, los cuales son abstracciones de más alto nivel que están construidas sobre el canal. Un ejemplo son las Tablas de Hash Distribuidas. Esta estructura se puede ver más claramente en la siguiente figura.. 3 4. Access Control Protocol DAV Searching and Locating. 14.

(15) ISC-2003-2-32. Figura III.1Arquitecutra JavaGroups[2]. Los canales pueden ser configurados para que usen una pila de protocolos determinada, lo que da al desarrollador la flexibilidad de seleccionar los servicios que son necesarios para su aplicación. Los protocolos disponibles en JavaGroups para configurar el canal son: UDP PING MERGE2 FD_SOCK. Permite usar IP multicast para enviar mensajes a los diferentes miembros del grupo. Usa IP multicast para encontrar a los demás miembros del grupo en el momento de creación del canal. Permite unir subgrupos en uno solo grupo. Permite la detección de fallas basada en sockets. Genera una. VERIFY_SUSPECT. notificación si un miembro falla. Permite hacer una doble verificación acerca de la posible falla. pbcast.Stable. de un miembro del grupo. Borra los mensajes que han sido vistos por todos los miembros. pbcast.NAKACK. del grupo. Garantiza que todos los mensajes son recibidos. También hace una verificación acerca del orden en que se envían y reciben. UNICAST. los mensajes (FIFO) Similar a NAKACK para mensajes unicast. 15.

(16) ISC-2003-2-32 FRAG. Permite la fragmentación y reconstrucción de mensajes tanto. pbcast.GMS TCP. en multicast como en unicast. Permite llevar el control sobre los miembros del grupo. Especifica el uso de TCP como mecanismo de comunicación. Los mensajes multicast se simulan enviando varios mensajes. TCPPING. multicast. Similar a PING sobre TCP Table 1Stack de Protocolos JavaGroups 5. III.2.2.2. JXTA JXTA[3] es un proyecto de código abierto que pretende definir mecanismos para la interacción entre aplicaciones y servicios p2p6. Para lograr esto JXTA define un conjunto de protocolos basados en XML que permite la independencia del lenguaje, sistema operativo y tecnología de comunicación. Dichos protocolos definen los mecanimos mínimos necesarios para construir un sistema p2p, la manera en que se debe hacer el descubrimiento de peers, grupos, servicios, la manera de comunicar y enrutar los mensajes dentro de la red, y la manera en que se hace el monitoreo de los peers. JXTA define los elementos básicos que debe tener una red p2p. Dichos elementos son: ➔. Peers: Son cada uno de los integrantes dentro de la red p2p. Cada peer puede proveer servicios y datos a los demás integrantes de la red.. ➔. Peer Groups: Son una manera de particionar la red. Cada grupo define los requisitos necesarios para acceder a él y los servicios que provee.. ➔. Services: Son los servicios que están disponibles en la plataforma. Básicamente cualquier servicio que se le ocurra al desarrollador, aunque hay una serie de servicios mínimos que debería tener cualquier implemetación de JXTA. Estos servicios son: PipeService, el encargado de manejar la manera en que se comunican los peers; MembershipService, que define la manera en que los peers pueden aplicar. 5 6. Tabla basada en al documentación de JavaGroups [2] Red en la que cada uno de los participantes se puede comunicar directamente con los demás integrantes de la red sin la necesidad de servidores centrales. 16.

(17) ISC-2003-2-32 para participar en un grupo; AccessService, que define la manera en que se limita o no el acceso a los recursos dentro de un grupo; DiscoveryService, que define la manera en que un peer descubre la existencia de otros peers, servicios y pipes; ResolverService, permite encontrar la manera en que los peers se refieren unos a otros dentro de la red. ➔. Pipes: Son una abstracción lógica mediante la cual se hace la comunicación dentro de JXTA. Son entidades unidireccionales y asincrónicas. Existen diferentes tipos: unicast, que permiten la comunicación uno a uno entre los peers; propagate, que permite encadenar un punto de salida con varios puntos de entrada y unicastSecure, que permite la comunicación segura a través de TLS.. Figura III.2 Tipos de Pipes en JXTA[3]. ➔. Advertisements: Son documentos XML a través de lo cuales se describen todos los elementos de la plataforma. Cada peer, peer group, pipe y servicio posee un advertisement.. La manera en que cada uno de estos elementos se integran dentro JXTA se puede observar a continuación:. 17.

(18) ISC-2003-2-32. Figura III.3 Arquitectura de JXTA[3]. En la actualidad el conjunto de protocolos definido por JXTA están siendo implementados en diferentes lenguajes como: J2SE, J2ME, C, Objetive-C, Rubby, Python, SmallTalk, entre otros. La comunidad que existe alrededor de JXTA ha estado creando diferentes servicios y aplicaciones que le dan más versatilidad al uso de esta plataforma. Dentro de estos servicios hay varios interesantes como XML-RPC, SOAP y voIP. Esto demuestra la gran fuerza que ha estado tomando el proyecto y la gran variedad de aplicaciones que se pueden construir sobre el.. III.3. Ambientes de Desarrollo. III.3.1. Eclipse Eclipse[1] surge alrededor del año 2001 como una propuesta innovadora por parte de IBM©, OTI(Object Technology International) y otras compañías que querían desarrollar una plataforma de código abierto que permitiera la integración entre diversas herramientas de desarrollo y que sirviera como una manera de capitalizar el desarrollo de 18.

(19) ISC-2003-2-32 herramientas en el lenguaje de programación Java. “Eclipse es un IDE para nada en particular”[19], que define una funcionalidad básica sobre la cuál es posible implementar herramientas de desarrollo para varios lenguajes como Java, C/C++, HTM, XML, entre otros. Todo esto es posible porque Eclipse está diseñado para descubrir, integrar y correr distintos módulos(plug-ins) que le dicen a la plataforma cuáles son las acciones que debe llevar a cabo ante la presencia de determinado tipo de recursos. Eclipse gira alrededor de tres ejes: El desarrollo de un ambiente de desarrollo para Java, la integración de diferentes herramientas, y la comunidad de desarrolladores open source que trabajan en él[20]. Como ambiente de desarrollo en Java, Eclipse provee al desarrollador de varias utilidades que le permiten escribir código de manera más rápida y eficiente. Estas herramientas son: Un editor especializado que provee funciones de asistencia de código, marcado de sintaxis, marcadores, revisión de sintaxis, etc.; un depurador y un esquema sencillo de integración con Ant y Junit. Todo este conjunto de características hace que la labor de codificación sea más sencilla para el desarrollador de Java, permitiéndole tener todas las herramientas para su trabajo en una sola aplicación. Como plataforma de integración, la arquitectura de Eclipse permite a los desarrolladores extender fácilmente las funcionalidades del IDE, esto a través de varios Frameworks y APIS, que hacen más fácil la interacción con la plataforma. Eclipse permite integrar varias herramientas dentro de sí, esto lo libra de la limitación de una metodología de trabajo particular, permite desarrollar fácilmente aplicaciones con Internacionalización y en algunos sistemas operativos, se integra con aplicaciones y tecnologías como el reconocimiento de voz que lo hacen una aplicación accesible a una amplia gama de usuarios. Como comunidad de código abierto, “la misión del proyecto Eclipse es adaptar y desarrollar la tecnología de Eclipse para satisfacer las necesidades de la comunidad de desarrolladores y de usuarios”[1]. Eclipse provee varias herramientas para que la colaboración entre los distintos miembros de la comunidad (corporaciones, investigadores y desarrolladores en general) puedan desarrollar herramientas inter-operables. 19.

(20) ISC-2003-2-32 El desarrollo de Eclipse está dividido en varios proyectos, cada uno de ellos con un comité propio (PMCs, Project Management Committees) que coordina su evolución y que administra las listas de correo, sistemas de control de errores y versiones que facilitan la colaboración entre sus miembros. Los principales proyectos alrededor de los cuales se desarrolla Eclipse son[1]: ➔. Eclipse Project: Dentro de él se desarrollan las herramientas que constituyen el núcleo de la Plataforma de Eclipse. Este está dividido en varios subproyectos: ➢. Platform: Este proyecto define el conjunto de frameworks y servicios que constituyen la base de la plataforma de integración de Eclipse. Estas ayudas incluyen la interfaz del workbench, SWT y la infraestructura de integración con sistemas de manejo de versiones.. ➢. JDT (Java Development Tools): Dentro de este subproyecto se desarrollan los plug-ins que permiten a Eclipse trabajar como un IDE para Java. Estos plugins pueden ser extendidos para facilitar el desarrollo de otros sistemas más especializados.. ➢. PDE (Plug-ing Develpment Enviroment): Define las vistas y editores que facilitan el desarrollo de plug-ins para Eclipse.. ➔. Eclipse Tools Project: Este proyecto está dedicado a desarrollar herramientas como editores, compiladores, depuradores, etc. para diferentes lenguajes de programación. Los subproyectos que lo constituyen son: ➢. CDT (C/C++ Development Tools): Este proyecto trabaja en el desarrollo de un IDE para el desarrollo de aplicaciones en C/C++ dentro de Eclipse.. ➢. GEF (Graphical Editor Framework): Define un framework para desarrollar editores gráficos sobre diferentes modelos. GEF permite la creación de editores de UML, WYSIWYG para HTML, etc.. ➢. COBOL: IDE para desarrollo de aplicaciones en COBOL.. 20.

(21) ISC-2003-2-32 ➢. Hyades: Este proyecto desarrolla herramientas de Automated Software Quality (ASQ), que sirven para probar, controlar y monitorear sistemas de software.. ➢. EMF: Es un framework de Java y XML para generar herramientas y aplicaciones que se basan en modelos de clases. Permite transformar fácilmente los modelos de clases en código Java. También permite representar los objetos como documentos XML.. ➢. VE (Eclipse Visual Editor): Es un framework para crear editores de GUI (Graphical User Interface). Incluye implementaciones de referencia para Swing/JFC, pero pretende definir la arquitectura para construir herramientas de este tipo para otros lenguajes como C/C++.. ➢ ➔. UML2: Es una implementación de la especificación de UML 2.0 sobre EMF.. Eclipse Technology Project: Este proyecto encapsula las iniciativas de investigación desarrolladas alrededor de Eclipse. Dichas investigaciones pueden ser exploraciones académicas, iniciativas educativas y herramientas innovadoras. ➢. AJDT(AspecJ Development Tools Project): Provee las herramientas para el desarrollo de aplicaciones con el nuevo paradigma AOSD (Aspect Oriented Software Development).. ➢. AspectJ: Implementación del compilador y herramientas básicas para el desarrollo de aplicaciones orientadas a aspectos en Java.. ➢. ECESIS(Eclipse Community Project): Promueve la creación, mejoramiento y distribución de cursos académicos y comerciales sobre Eclipse.. ➢. Equinox: Este proyecto experimenta con técnicas para ampliar el rango de las configuraciones del runtime de Eclipse, como por ejemplo PDA's, y otros ambientes con restricciones.. ➢. Koi: Este proyecto esta implementando la infraestructura para desarrollar actividades colaborativas dentro de Eclipse.. ➢. Stellation: Es un sistema manejador de configuraciones de software. Este 21.

(22) ISC-2003-2-32 proyecto se enfoca en la organización dinámica de programas y la coordinación inter-programas. ➢. WSVT (Web Service Validation Tools): Este proyecto provee herramientas para la validación de los Web Services durante las etapas de desarrollo, deploy, pruebas y depuración. Estas herramientas son: un validador de WSDL (versiones 1.1 y 1.2) y un validador de mensajes SOAP.. ➢. XSD: Es una librería para modificar y examinar XML Schemas.. ➢. GMT (Generative Model Transformer): Este proyecto pretende construir una serie de herramientas que permitan el desarrollo de software basado en modelos.. ➔. Eclipse Web Tools Platform Project: Este proyecto pretende desarrollar herramientas que permitan a los desarrolladores crear aplicaciones Web que se puedan integrar fácilmente con cualquier servidor que implemente la especificación de J2EE.. La licencia bajo la cuál se distribuye la mayor parte del código de Eclipse es la Common Public Licence (Ver anexo 1), que permite a los desarrolladores el uso comercial de software y la libre redistribución del código fuente del mismo. La ventaja de esta aproximación en la distribución del software es que impulsa la evolución del mismo porque incluye al cliente como un posible co-desarrollador. III.3.1.1. Arquitectura de Eclipse Una de las características más importantes de Eclipse es su arquitectura. El diseño de Eclipse fue guiado desde el principio por la extensibilidad. La manera en que se definen nuevas funcionalidades para la plataforma es a través de los plug-ins (un plug-in es la mínima unidad funcional que reconoce Eclipse). Uno puede construir herramientas a partir de uno o más plug-ins. La manera en que estos plug-ins se integran a Eclipse es por medio de los puntos de extensión (extension points). Cada punto de extensión es un lugar donde el desarrollador puede extender la plataforma (u otro plug-in que este instalado. 22.

(23) ISC-2003-2-32 dentro de ella) y define la información que necesita para manejar las contribuciones que se hagan sobre este. La manera en que cada plug-in se relaciona con los otros plug-ins en la plataforma, está definida en el archivo descriptor del plug-in (plug-in manifest), un archivo XML que contiene toda la información que se necesita para poder instanciar un plug-in, define sus dependencias, los nuevos puntos de extensión que el plug-in provee, y las extensiones o contribuciones a puntos de extensión de la plataforma u otros plug-ins. La manera en que este archivo es usado por la plataforma es la siguiente: Al iniciarse Eclipse la plataforma descubre y carga la información de los descriptores de cada plug-in y crea en memoria el registro de plug-ins; con esta información la plataforma puede iniciarse rápidamente pues no necesita cargar cada plug-in para descubrir su funcionalidad, de hecho, un plug-in sólo se carga en el instante que se requieren sus funcionalidades. La arquitectura de Eclipse esta formada por varios componentes:. Figura III.4 Arquitectura Eclipse[1]. ✔. Platform Runtime: Es el único componente de Eclipse que no está construido a partir de plug-ins. El runtime de la plataforma está encargado de manejar los plug-ins, leer los descriptores y construir el registro de plug-ins. 23.

(24) ISC-2003-2-32 ✔. Workspace: Es el componente de Eclipse que está encargado de administrar los "recursos" que están disponibles para Eclipse. El recurso de más alto nivel es un proyecto, que está compuesto de directorios y archivos. Cada proyecto puede tener una o más "naturalezas" (natures), que definen el tipo de recursos que contiene el proyecto. Por ejemplo, todos los proyectos Java tienen la "Java Nature". Adicionalmente el Workspace administra el mecanismo que mantiene el historial de modificaciones sobre los recursos y administra el sistema de "marcadores" que sirven para almacenar diferentes anotaciones sobre los recursos, como errores de compilación, puntos de control, etc.. ✔. Workbench: Este componente de la arquitectura de Eclipse es el encargado de coordinar los elementos visuales de la plataforma. Provee las vistas, editores y perspectivas que constituyen la UI de Eclipse. La implementación del workbench está construida sobre dos toolkits SWT y JFace. SWT es el conjunto de widgets que está integrada con el sistema operativo, lo que facilita la integración de Eclipse con el ambiente que los usuarios están acostumbrados. JFace es un toolkit que está construido sobre SWT, provee los registros de imágenes, fuentes y preferencias, define interfaces de alto nivel para el manejo de eventos (actions) y "viewers" que facilitan la representación de los datos en widgets de alto nivel como listas, tablas y árboles.. 24.

(25) ISC-2003-2-32. Figura III.5Arquitectura del Workbench. ✔. Team: Es el componente de la plataforma que se encarga de coordinar que los elementos del workspace puedan ser compartidos a través de un sistema de versiones, como CVS, Subversion, etc.. ✔. Help: Es el componente de la plataforma que le permite definir ayudas sobre los plug-ins o documentación de los API's para facilitar el trabajo de los desarrolladores.. 25.

(26) ISC-2003-2-32. IV. Requerimientos de Zerankwa Zerankwa es una plataforma de edición colaborativa de software dentro de Eclipse. Los requerimientos de este plug-in se dividen en dos grupos: Los requerimientos inherentes a los sistemas distribuidos y los requerimientos que brindan las funcionalidades de colaboración.. IV.1. Requerimientos de Sistemas Distribuidos Los servicios mínimos que toda aplicación distribuida (incluyendo a Zerankwa) debe brindar son[11]: ➢. Disponibilidad: Los usuarios deben poderse conectar a la red en cualquier momento.. ➢. Autenticidad: El sistema debe ser capaz de autenticar a los usuarios con login y password.. ➢. Control de Acceso: El sistema debe restringir el acceso a los recursos, para mantener la privacidad de los datos del usuario.. ➢. Independencia de la ubicación: El usuario debe poder acceder a los recursos de la red independientemente de su ubicación geográfica.. ➢. Independencia de la plataforma: El usuario debe poder acceder a los servicios de la plataforma independientemente del sistema operativo sobre el que esté trabajando.. IV.2. Requerimientos de la plataforma colaborativa. ➢. Configuración de la red: Permitir la configuración de la red en varios niveles. Esto incluye la configuración de servidores centralizados (en caso de ser necesarios) y los puertos que usuarán para la comunicación.. ➢. Creación y configuración del usuario: Permitir la configuración de los datos del usuario. Login y password para acceder a la plataforma, e información adicional que se 26.

(27) ISC-2003-2-32 quiere poner a disposición de los demás integrantes de la red. ➢. Creación de grupos de trabajo: Permitir la creación de diferentes grupos de trabajo. Cada grupo debe tener un password para restringir el acceso de los usuarios al mismo. Estos grupos se pueden asignar a cada proyecto dentro de Eclipse.. ➢. Servicio de Mensajería Instantánea: Proveer un sistema de mensajería instantánea para permitir a los usuarios comunicarse sincrónicamente independientemente de si está trabajando conjuntamente en un archivo de código fuente o no.. ➢. Elegir colaborador: Permitir listar los usuarios que están conectados a la red y elegir a uno de ellos para trabajar conjuntamente con él en uno o más archivos.. ➢. Edición colaborativa: Permitir que dos usuarios puedan compartir la vista de un editor. Uno de ellos tendrá la posibilidad de modificar los contenidos del archivo mostrado por el editor, y el otro debe poder observar los cambios de manera sincrónica, incluyendo los desplazamientos sobre el archivo (scroll).. ➢. Compilación remota: Permitir lanzar remotamente el proceso de compilación para verificar que los cambios hechos sincrónicamente no producen errores.. ➢. Compartir la vista de consola: Permitir que los usuarios que intervienen en la sesión de edición colaborativa compartan la salida de la consola para poder ver conjuntamente los mensajes de depuración que se muestren en ella.. Es importante precesisar que la implementación de estos requerimientos sobre el API de JXTA implica algunos refinamientos, entre ellos: ➢. Configuración de la red y de usuario: En Zerankwa se pueden definir dos tipos de redes:. 27.

(28) ISC-2003-2-32 1. Red de colaboradores segura: Una red de colaboradores segura se define como una red JXTA en la que por lo menos existe un Rendezvous especial que provee las funcionalidades de creación de grupos de trabajo y autenticación. Del mismo modo tiene la capacidad de interactuar con otras aplicaciones que proveen servicios dentro de la organización como herramientas de seguimiento de Tareas, Servidores de Usuarios, entre otros. 2. Red de colaboradores pública: Una red de colaboradores publica es una red adhoc que utiliza la infraestructura de la red JXTA como medio de comunicación. Los grupos de trabajo en este tipo de red se definen por la creación de grupos JXTA seguros, que garanticen la privacidad de los recursos que se comparten dentro de la plataforma. Para la configuración de cada una de estas redes el plug-in permite: ✔. Definición de el/los Rendevous y Relay. Dichos Peers especiales pueden ser privados (es decir pertenecientes a la red de colaboradores segura) o públicos (los que provee JXTA); esto para dar más versatilidad en el uso del plug-in.. ✔. Definición del nombre, login y password del peer. En el caso de estar trabajando en una red de colaboradores segura, el Rendezvous privado deberá autenticar a los usuarios.. ✔ ➢. Configuración de los puertos utilizados por el plug-in para comunicarse.. Creación de grupos de trabajo: La definición de los grupos de trabajo dentro de Zerankwa se hace por proyecto. En el momento de la creación del grupo se debe especificar una contraseña de acceso.. ➢. Elegir colaborador: Zerankwa permite seleccionar un colaborador entre los miembros del grupo que estén conectados. Después de seleccionar el colaborador, el usuario podrá escoger entre enviar un mensaje instantáneo o hacer un requerimiento para compartir el editor que se encuentre abierto actualmente; en este caso también se debe poder especificar si se desea que el colaborador pueda o no abrir más archivos que él seleccionado. 28.

(29) ISC-2003-2-32 ➢. Edición colaborativa: En el proceso de edición colaborativa sólo podrá tener la capacidad de cambiar el código la persona que tenga el control de la sesión de colaboración. En caso de que haya pasado un tiempo considerable sin ningún tipo de interacción entre los participantes de la sesión, el control del archivo debe volver invariablemente al propietario del archivo.. 29.

(30) ISC-2003-2-32. V. Diseño e Implementación de Zerankwa El diseño e implementación de Zerankwa será explicado en esta sección. Primero se mostrará un descripción de la arquitectura del plug-in, cuáles son los componentes que interactúan dentro de él y el papel que cada uno de ellos en la ejecución de la plataforma. Luego se mostrará en detalle la funcionalidad de cada uno de estos componentes y se discutirán los pormenores de su implementación.. V.1. Arquitectura de Zerankwa. Figura V.1 Arquitectura Zerankwa. Zerankwa esta dividido en tres grandes componentes: ➔. Zerankwa UI (Interfaz gráfica): Es el encargado de brindar la visualización de los 30.

(31) ISC-2003-2-32 distintos elementos que interactúan dentro de la plataforma como grupos, usuarios y mensajes, así como de mostrar las interfaces para configurar la red y el proyecto. Los elementos de visualización definidos por este componente y que se ven reflejados en el workbench de Eclipse son: ✔. Vista de grupos y usuarios: Esta vista muestra la lista de grupos activos en la plataforma y los usuarios que actualmente están conectados(Ver figura 1 del anexo 2).. ✔. Vista de Mensajes: Esta vista se muestra cada vez que se inicia un conversación con un miembro del equipo de trabajo (Ver figura 2 del anexo 2).. ✔. Página de preferencias: Esta página es mostrada en el menú Window->Preferences de Eclipse. Permite configurar los rendezvous y relays usados por JXTA para realizar la comunicación y el nombre del usuario(peer) (Ver figura 3 del anexo 2).. ✔. Página de Propiedades: Esta página es mostrada al seleccionar la opción Properties en un proyecto Java dentro del navigator de Eclipse. Aquí se configura y/o crea el grupo habilitado para compartir los recursos de ese proyecto (Ver figura 4 del anexo 2).. ✔. Extensiones al menú desplegable de Eclipse: Estas opciones permiten configurar, iniciar y desactivar a Zerankwa para un proyecto de Eclipse (Ver figura 5 del anexo 2).. ✔. Editor colaborativo: Es una extensión del editor que provee el JDT7, que muestra de manera sincrónica los cambios hechos en un archivo por las personas envueltas en una sesión de colaboración.. ➔. Zerankwa Core (Lógica del plug-in): Es el encargado de manejar la interacción entre los distintos elementos del modelo y está construído directamente sobre la plataforma de comunicación. Define el punto de extensión del plug-in y los servicios que brinda la plataforma.. 7. Java Development Tool, plug-in que provee las funcionalidades de un IDE de Java,. 31.

(32) ISC-2003-2-32 El punto de extensión definido por el plug-in es communicator, que define los servicios básicos que debe tener la implementación de Zerankwa sobre cualquier plataforma de comunicación. Estos servicios son: ✔. Creación de grupos: Permite la creación de un grupo con nombre, descripción y contraseña.. ✔. Unirse a un grupo: Permite unirse a un grupo después de llevar a cabo el proceso de autenticación correspondiente.. ✔. Separarse de un grupo: Permite separarse de un grupo.. ✔. Enviar mensajes instantáneos: Envío de mensajes instantáneos al usuario seleccionado.. ✔. Enviar notificación de eventos: Notificación de los eventos que suceden sobre el editor en una sesión de colaboración.. ✔. Iniciar la plataforma: Inicia los canales de comunicación usados por la plataforma.. ✔. Detener la plataforma: Detiene/destruye los canales de comunicación usados por la plataforma.. ➔. Plataforma de comunicación(JXTA): Es la plataforma tecnológica usada para realizar la comunicación. En este caso JXTA que provee los servicios necesarios para implementar los servicios básicos de un sistema distribuido (Ver capítulo 3, sección 1).. V.2. Implementación de Zerankwa Zerankwa se divide en dos plug-ins: co.edu.uniandes.zerankwa.gui(Zerankwa UI) y co.edu.uniandes.zerankwa (Zeranwka Core), que se distribuyen juntos por medio de un Feature8. Los detalles de la implementación de estos plug-ins, será mostrada a continuación.. 8. Una de las esquemas que provee eclipse para distribuir varios plug-ins interdependientes de manera agrupada.. 32.

(33) ISC-2003-2-32. V.2.1. co.edu.uniandes.zerankwa.gui Este plug-in esta compuesto por los elementos gráficos de la plataforma colaborativa y está organizado en varios paquetes (Ver figura 1 del anexo 3) de la siguiente manera: ➔. co.edu.uniandes.zerankwa.gui Contiene la clase que identifica el plug-in ante Eclipse, esta clase contiene los métodos utilitarios necesarios para la correcta integración del plug-in con Eclipse.. ➔. co.edu.uniandes.zerankwa.actions Contiene las clases que implementan las interfaces IActionDelegate y que son usadas por Eclipse para designar los objetos que realizan alguna acción dentro del workbench. ✔. ZerankwaActivatorAction: Clase que implementa la acción de inicializar la plataforma.. ✔. ZerankwaMenuAction: Clase que implementa la acción de habilitar un proyecto para el uso de la plataforma.. ➔. co.edu.uniandes.zerankwa.dialogs Contiene las clases que muestran algún tipo de retroalimentación al usuario a través de diálogos. ✔. GroupAuthDialog: Diálogo que pide la contraseña de autenticación del grupo.. ✔. NewGroupWizard: Diálogo que muestra el wizard de creación de grupo.. ✔. NewGroupWizardPage: Página del diálogo de creación de grupo.. ✔. RdvRelayAutoLoader: Diálogo que muestra el proceso de autocarga de los RendezVous y Relays necesarios para la configuración de la plataforma.. ➔. co.edu.uniandes.zerankwa.monitors Contiene las clases que implementan algún monitor que muestra el avance en la realización de una tarea. ✔. LoadServersOperation: Clase que implementa el monitor que da la 33.

(34) ISC-2003-2-32 retroalimentación cuando se está cargando los servidores (Rendezvous y Relays). ➔. co.edu.uniandes.zerankwa.preferences Contiene las clases que implementan las páginas de configuración para el plug-in. ✔. ZerankwaPreferencesPage: Clase que implementa la página de preferencias en la que se configuran los datos del peer y de los servidores usados por la plataforma.. ✔. ZerankwaPropertyPage: Clase que implementa la página de propiedades. Permite configurar el grupo de trabajo para el proyecto.. ➔. co.edu.uniandes.zerankwa.views Contiene las clases que implementan las vistas contribuidas por el plug-in. ✔. ZerankwaUsersView: Clase que implementa la vista que muestra los grupos activos en la plataforma.. ✔. ZerankwaChatView: Clase que implementa la vista en la que los usuarios pueden enviar y recibir mensajes instántaneos.. ✔. UserConversationView: Clase que implementa una conversación dentro de la vista del chat.. ✔. UserMessageAction: Es la clase encargada de crear la vista de chat cuando se selecciona un usuario. Las siguientes clases son las que implementan el patrón MVC en el esquema propuesto por SWT.. ✔. UserLabelProvider: Es la clase encargada de mostrar las etiquetas de los objetos mostrados en el árbol que representa los grupos y usuarios.. ✔. UserContentProvider: Es la clase encargada de manejar los objetos que deben ser mostrados en el árbol de grupos y usuario.. 34.

(35) ISC-2003-2-32. V.2.2. co.edu.uniandes.zerankwa Este plug-in es el encargado de la lógica de la plataforma colaborativa y define el punto de extensión que puede ser usado para implementar la misma funcionalidad con una tecnología de comunicación diferente a JXTA. Los paquetes (Ver figura 1 del anexo 4) que hacen parte de este plug-in son: ➔. co.uniandes.zerankwa Contiene la clase que identifica el plug-in ante Eclipse, y las interfaces que se debe implementar para cumplir con los requerimientos de la plataforma. ✔. ZerankwaPlugin: Clase que identifica el plug-in ante Eclipse.. ✔. IZerankwaManager: Interfaz que define los servicios del modelo de Zerankwa. Esta clase debe ser implementada por los desarrolladores que deseen extender el punto de extensión communicator definido por el plug-in.. ✔. IZerankwaGroup: Interfaz que define los servicios que debe proveer un grupo para integrarse fácilmente con la interfaz.. ➔. co.uniandes.zerankwa.jxta Contiene las clases que implementan el modelo de Zerankwa sobre JXTA. Las principales clases de este paquete son: ✔. ZerankwaJxtaManager: Clase que implementa la servicios definidos en la interfaz IZerankaManager sobre JXTA.. ✔. JxtaConfigurator: Clase que se encarga de cargar y procesar el archivo de configuración de JXTA.. ✔. JxtaServiceManager: Clase que provee los servicios remotos de la plataforma.. ✔. ZerankwaJxtaGroup: Clase que implementa los servicios definidos por la interfaz IZerankwaGroup. ✔. IAuthenticator: Interfaz que define los métodos que deben tener las clases que se 35.

(36) ISC-2003-2-32 usen para implementar el servicio de autenticación dentro de la plataforma.. ➔. ✔. DefaultAuthenticator: Implementación por defecto de IAuthenticator.. ✔. IZerankwaConstants: Interfaz que define las constantes usadas por la plataforma.. co.uniandes.zerankwa.jaas Este paquete contiene las clases que implementan el MembershipService de JXTA sobre JAAS[21]9(Ver figura 2 del anexo 4). ✔. ZerankwaMembershipService:. Clase. que. implementa. la. interfaz. MembershipService de JXTA sobre JAAS. Esta interfaz define los servicios que debe proveer un servicio de autenticación de usuarios a nivel de grupo dentro de JXTA. ✔. ZerankwaCredential: Clase que implementa la interfaz Credential que identifica al usuario autenticado dentro de JXTA.. ✔. IZerankwaCallbackHandler: Interfaz que define los métodos del CallbackHandler que usa el MembershipService para hacer la autenticación.. ✔. ZerankwaCallbackHandler:. Implementación. por. defecto. de. la. interfaz. IZerankwaCallbackHandler. ✔. ZerankwaLoginModule: Clase que implementa la interfaz LoginModule de JAAS.. Este MembershipService se creó a raíz de la necesidad de tener un mecanismo estandar y fácilmente extendible con la cual el plug-in se pudiera integrar con los otros sistemas dentro de una organización. Se escogió JAAS debido a su versatilidad, porque hace fácil la labor de cambiar el mecanismo de autenticación sin necesidad de cambiar toda la aplicación, y por que hace sencilla la integración con nuevos esquemas de autenticación y autorización de los usuarios. La configuración de la autenticación usando JAAS se hace por medio del archivo JxtaConfig.xml que especifica las siguientes propiedades:. 9. Java Authentication and Authorization Service. 36.

(37) ISC-2003-2-32. <zerankwaxmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="zerankwa.xsd"> <auth> <JxtaRealm memberShipService=""> <Authenticator class=""> <options> <option name="String" value="String"/> </options> </Authenticator> <LoginModule class="" controlFlag="required"> <options> <option name="UnaOPcion" value="String"/> </options> </LoginModule> </JxtaRealm> </auth> <services remoteServers="true"/> </zerankwa>. El papel de cada uno de estos tags en la configuración del método de autenticación se explica a continuación: ➢. JxtaRealm:. Permite. configurar. la. clase. que. implementa. la. interfaz. MemberShipService de JXTA. ➢. Authenticator:. Permite configurar la clase que implementa la interfaz. IAuthenticator de Zerankwa. ➢. LoginModule: Permite especificar el/los LoginModules usados por el MembershipService, el atributo controlFlag, puede tomar los valores requerido u opcional. Para que un usuario sea autenticado debe lograr autenticarse con todos los LoginModule que tengan especificado el controlFlag requerido.. ➢. Services: Permite configurar si la plataforma permite la búsqueda de servidores rendezvous y relay remotos.. 37.

(38) ISC-2003-2-32. VI. Evaluación El desarrollo de Zerankwa requirió la exploración de varias tecnologías: JXTA, JAAS, SWT y el mismo Eclipse. A continuación se hará un recuento de los pros y contras de la utilización de cada uno de estos API's.. VI.1. Eclipse y SWT Eclipse provee varias facilidades para trabajar sobre él. Esta compuesto por varios API's especializados, que reducen la cantidad de código que se tiene que escribir para desarrollar una funcionalidad. En general, desarrollar sobre Eclipse es sencillo, la documentación que viene con la plataforma en la mayoría de los casos es suficiente para solucionar las dudas que aparecen durante la implementación, aunque hay muchas otras que no son obvias y hacen necesaria la inspección del código de la plataforma. También son muy útiles los artículos que se encuentran en el sitio de Eclipse[1], y en general son el mejor punto de partida para entender los conceptos básicos del desarrollo para Eclipse. SWT es el API sobre el que esta implementado el workbench de Eclipse. Para los desarrolladores acostumbrados a Swing y AWT es definitivamente un nuevo paradigma. La manera en que SWT maneja aspectos como los layout, las imágenes, los thread de ejecución, difieren enormemente con la manera tradicional de desarrollar aplicaciones gráficas en Java. En algunos casos estas diferencias facilitan el trabajo del desarrollador, como en el caso de los layouts, que hacen que la ubicación de los objetos gráficos sea muy similar a crear una tabla HTML. Otros como el manejo de imágenes, en SWT es necesario liberar las imágenes cuando no se esta mostrando el componente, obligan al desarrollador a estar pendiente de aspectos con los que usualmente no tiene que tratar. Lo mismo pasa con el manejo de los threads de ejecución que están encargados de mostrar los elementos gráficos, para hacer una actualización sobre un objeto es necesario hacer mucho más código (esto depende del API que este usuando, JFace facilita muchas cosas, pero no se puede usar siempre), y puede ser un dolor de cabeza para un desarrollador poco expermientado en este API. Para desarrollar los aspectos gráficos dentro de Eclipse es 38.

(39) ISC-2003-2-32 recomendable usar JFace en lugar de SWT en la medida de lo posible, este API encapsula varios de los aspectos “problemáticos” del desarrollo con SWT. En resumen, desarrollar para Eclipse es una tarea relativamente sencilla, debido a las fácilidades que da la manera en que éste está construido. La mayor parte de los inconvenientes que se pueden presentar son debidos a la integración con el workbench que implica la utilización de SWT. Con base en la experiencia ganada en el desarrollo de este proyecto, se recomienda seguir los siguientes pasos en caso de encontrar dudas durante el desarrollo de herramientas para Eclipse: 1. Artículos que están en el sitio web de Eclipse 2. Buscar en la documentación que viene con la plataforma. 3. Mirar el código fuente de la plataforma. 4. Consultar las listas de correo de los diferentes subproyectos que conforman Eclipse.. VI.2. JXTA Aunque JXTA soluciona gran parte de los problemas importantes inherentes a la comunicación en un ambiente p2p, al ser básicamente una especificación más que un framework, hay que desarrollar muchas cosas sobre él para tener una aplicación funcional. Por fortuna, la manera en que JXTA está diseñado lo hace muy flexible. El desarrollo de servicios sobre él es relativamente sencillo y gracias a que es un proyecto de código abierto, existen varias iniciativas interesantes que se pueden consultar en el sitio del proyecto[3]. En el desarrollo de Zerankwa se hizo uso del proyecto jaas-membership[22], que se tomo como punto de partida para la implementación del servicio de autenticación, y xmlrpc[23], un proyecto de JXTA que implementa XML-RPC sobre JXTA, y que fue usado en Zerankwa para el llamado remoto de las acciones necesarias para mostrar los cambios en el workbench. Una de la mayores dificultades en la trabajo con JXTA fue la de garantizar la presencia de. 39.

(40) ISC-2003-2-32 los otros usuarios, esto debido a que no existe (o no esta debidamente documentado) un servicio sobre JXTA que permita monitorear el estado de la conexión con los otros usuarios. Otro aspecto difícil de manejar fueron los caches, estos juegan un papel fundamental dentro de JXTA, pues ayudan a minimizar el tráfico de la red, pero pueden llegar a ser un dolor de cabeza, cuando se necesita garantizar la existencia de un mismo recurso en una red tan variable como la p2p. En Zerankwa esto fue una gran dificultad pues en este tipo de aplicación era necesario que el grupo en que estuvieran trabajando los usuarios fuera el mismo, y si la caducidad de los caches no era la adecuada, se podrían crear dos “instancias” de un mismo grupo que no podrían comunicarse mutuamente. JXTA es una tecnología muy joven, todavía tiene muchas falencias como las aquí mencionadas, pero se puede considerar lo suficientemente madura como para desarrollar aplicaciones distribuidas de mediana complejidad. Su flexibilidad permite a los usuarios construir sobre ella aquellos servicios que se consideren interesantes.. VII. Conclusiones y trabajos futuros Dentro del contexto del Global Software Development, la necesidad de herramientas que fáciliten el trabajo de grupos de desarrollo distribuidos es algo latente. Zerankwa como plataforma de trabajo colaborativo sobre Eclipse, pretende solucionar uno de estos aspectos, en especial, la solución rápida de problemas encontrados durante la fase de codificación. El desarrollo de Zerankwa permitió explorar varias tecnologías para la implementación de aplicaciones que solucionen estos problemas. En particular permtió evaluar la viabilidad del desarrollo de herramientas colaborativas dentro de Eclipse y el impacto del esquema de comunicaciones p2p en el desarrollo de aplicaciones distribuidas. Eclipse como proyecto de código abierto es un excelente punto de partida para el desarrollo de diferentes herramientas que asistan la labor del desarrollador, ya sean estas sincrónicas o asincrónicas. La madurez y robustez de su diseño permite que el desarrollador se enfoque únicamente en los aspectos relevantes de su herramienta, y lo. 40.

(41) ISC-2003-2-32 convierte en una buena alternativa para la implementación de aplicaciones de trabajo colaborativo. Por su parte JXTA, como especificación y plataforma de desarrollo para aplicaciones p2p está todavia en sus inicios, sin embargo está tomando mucha fuerza. Su independencia del lenguaje de programación y la gran cantidad de desarrolladores que trabajan en el proyecto lo hacen una buena elección para la implementación de este tipo. Trabajar con JXTA simplifica al desarrollador muchas de las labores típicas de los sistemas distribuidos. Para poder evaluar correctamente el desempeño de JXTA en la implementación de sistemas p2p es necesario buscar iniciativas similares e implementar aplicaciones sobre ellas. Futuros trabajos basados sobre Zerankwa podrian ser extensiones del plug-in implementadas sobre otras tecnologías de comunicación, no necesariamente p2p, que permitan evaluar cuales son los aspectos críticos a tener en cuenta en el desarrollo de aplicaciones de trabajo colaborativo. También se podría extender las funcionalidades de Zerankwa implementando servicios como la comunicación de voz sobre IP, o video, para hacer la comunicación mas interactiva, ayudando de esta manera a fortalecer los lazos de confianza entre los miembros del equipo. Otro aspecto a tener en cuenta es mejorar las capacidades del plug-in para integrarse con otras herramientas que apoyen el trabajo de grupos distribuidos.. 41.

(42) ISC-2003-2-32. VIII. Bibliografía. [1] Eclipse Project http://www.eclipse.org [2] Java Groups http://www.jgroups.org/ [3] Project JXTA http://www.jxta.org/ [4] Global Software Development: The Bell Labs Collaboratory http://www.cs.uoregon.edu/~darkins/papers/icse-collab.pdf [5] WebDAV http://www.webdav.org [6] RFC 2518 http://andrew2.andrew.cmu.edu/rfc/rfc2518.html [7] WebDAV - FAQ http://www.webdav.org/other/faq.html [8] Whitehead, James. Collaborative Authoring on the Web http://www.asis.org/Bulletin/Oct-98/webdav.html [9] Whitehead,James. WebDAV Next Generation web Infrasture http://www.ics.uci.edu/~ejw/http-future/whitehead/http_pos_paper.html [10] Fred Dridi, Gustaf Neuman. How to implement Web-based Groupware Systems based en WebDAV http://nestroy.wi-inf.uni-essen.de/Forschung/Publikationen/WETICE99/webdav42.

(43) ISC-2003-2-32 client-impl/ [11] 2003, Bowen Seth. Using a P2P Architecture to Support Distributed Software Development http://sern.ucalgary.ca/~milos/papers/2003/Bowen2003.pdf [12] De Souza, Basaveswara,Redmiles.Supporting Global Software Development with Event Notification Servers http://www.cis.ohio-state.edu/~nsridhar/ICSE02/GSD/PDF/Desouza.pdf [13] Atkins, Handel, Hersbleb, Mockus, Perry, Wills. Global Software Development: The Bell Labs Collaboratory http://www.cs.uoregon.edu/~datkins/papers/icse-collab.pdf [14] Kotlarsky, Kumar, Hillegersberg. Coordination and Collaboration for Global Distributed Teams: The Case of Component-Based/Object-Oriented Software Development http://www.cis.ohio-state.edu/~nsridhar/ICSE02/GSD/PDF/Kotlarsky.pdf [15] Lanubile. A P2P Toolset for Distributed Requirements Elicitation http://gsd2003.cs.uvic.ca/upload/Lanubile.pdf [16] Chanjaraspong. Is Your Company for Global Software Development? http://www.cs.uh.edu/~nattawat/se/termpaper-se.pdf [17] Sarma, van der Hoek. Palantír: Increasing Awareness in Distributed Software Development http://www.ics.uci.edu/~andre/research/papers/IWGSD2002.pdf [18] Boulila, Dutoi, Brügge. D-Metting: an Object-Oriented Framework for Supporting Distributed Modeling of Software http://wwwbruegge.in.tum.de/publications/includes/pub/boulila2003dmeeting/boulila200 3dmeeting.pdf. 43.

(44) ISC-2003-2-32 [19] 2003, Object Technology International Inc. Eclipse Platform Technical Overview http://www.eclipse.org/whitepapers/eclipse-overview.pdf [20] Shavor, D'Anjou, Fairbrother, Kehn, Kellerman, McCarthy. The Java Developers Guide to Eclipse, Addison Wesley, 2003 [21]Java Authentication and Authorization Service http://java.sun.com/products/jaas/ [22] JAAS implementation of the JXTA Membership Service http://jaas-membership.jxta.org/servlets/ProjectHome [23] XML-RPC for JXTA http://xmlrpc.jxta.org/servlets/ProjectHome. 44.

(45) ISC-2003-2-32. IX. Anexo 1: Common Public License v 1.0 1. DEFINITIONS "Contribution" means: a) in the case of the initial Contributor, the initial code and documentation distributed under this Agreement, and b) in the case of each subsequent Contributor: i) changes to the Program, and ii) additions to the Program; where such changes and/or additions to the Program originate from and are distributed by that particular Contributor. A Contribution 'originates' from a Contributor if it was added to the Program by such Contributor itself or anyone acting on such Contributor's behalf. Contributions do not include additions to the Program which: (i) are separate modules of software distributed in conjunction with the Program under their own license agreement, and (ii) are not derivative works of the Program. "Contributor" means any person or entity that distributes the Program. "Licensed Patents " mean patent claims licensable by a Contributor which are necessarily infringed by the use or sale of its Contribution alone or when combined with the Program. "Program" means the Contributions distributed in accordance with this Agreement. "Recipient" means anyone who receives the Program under this Agreement, including all Contributors. 2. GRANT OF RIGHTS a) Subject to the terms of this Agreement, each Contributor hereby grants 45.

(46) ISC-2003-2-32 Recipient a non-exclusive, worldwide, royalty-free copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, distribute and sublicense the Contribution of such Contributor, if any, and such derivative works, in source code and object code form. b) Subject to the terms of this Agreement, each Contributor hereby grants Recipient a non-exclusive, worldwide, royalty-free patent license under Licensed Patents to make, use, sell, offer to sell, import and otherwise transfer the Contribution of such Contributor, if any, in source code and object code form. This patent license shall apply to the combination of the Contribution and the Program if, at the time the Contribution is added by the Contributor, such addition of the Contribution causes such combination to be covered by the Licensed Patents. The patent license shall not apply to any other combinations which include the Contribution. No hardware per se is licensed hereunder. c) Recipient understands that although each Contributor grants the licenses to its Contributions set forth herein, no assurances are provided by any Contributor that the Program does not infringe the patent or other intellectual property rights of any other entity. Each Contributor disclaims any liability to Recipient for claims brought by any other entity based on infringement of intellectual property rights or otherwise. As a condition to exercising the rights and licenses granted hereunder, each Recipient hereby assumes sole responsibility to secure any other intellectual property rights needed, if any. For example, if a third party patent license is required to allow Recipient to distribute the Program, it is Recipient's responsibility to acquire that license before distributing the Program. d) Each Contributor represents that to its knowledge it has sufficient copyright rights in its Contribution, if any, to grant the copyright license set forth in this Agreement. 46.

(47) ISC-2003-2-32 3. REQUIREMENTS A Contributor may choose to distribute the Program in object code form under its own license agreement, provided that: a) it complies with the terms and conditions of this Agreement; and b) its license agreement: i) effectively disclaims on behalf of all Contributors all warranties and conditions, express and implied, including warranties or conditions of title and non-infringement, and implied warranties or conditions of merchantability and fitness for a particular purpose; ii) effectively excludes on behalf of all Contributors all liability for damages, including direct, indirect, special, incidental and consequential damages, such as lost profits; iii) states that any provisions which differ from this Agreement are offered by that Contributor alone and not by any other party; and iv) states that source code for the Program is available from such Contributor, and informs licensees how to obtain it in a reasonable manner on or through a medium customarily used for software exchange. When the Program is made available in source code form: a) it must be made available under this Agreement; and b) a copy of this Agreement must be included with each copy of the Program. Contributors may not remove or alter any copyright notices contained within the Program. Each Contributor must identify itself as the originator of its Contribution, if any, in a manner that reasonably allows subsequent Recipients to identify the originator of the 47.