ZERANKWA PLATAFORMA DE DESARROLLO COLABORATIVO CON …
58
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
Transcript of ZERANKWA PLATAFORMA DE DESARROLLO COLABORATIVO CON …
ISC-2003-2-32
ZERANKWAPLATAFORMA DE DESARROLLO COLABORATIVO CON
ECLIPSE
DIEGO ANDRÉS RAMÍREZ ARAGÓN
UNIVERSIDAD DE LOS ANDESFACULTAD DE INGENIERÍA
DEPARTAMENTO DE SISTEMAS Y COMPUTACIÓNBOGOTÁ, ENERO DE 2004
1
ISC-2003-2-32
ZERANKWAPLATAFORMA 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
AsesorRubby Casallas
Doctora en Informática
UNIVERSIDAD DE LOS ANDESFACULTAD DE INGENIERÍA
DEPARTAMENTO DE SISTEMAS Y COMPUTACIÓNBOGOTÁ, ENERO DE 2004
2
ISC-2003-2-32
Tabla de ContenidoI. Introducción.........................................................................................................................6III. Marco Teórico.................................................................................................................. 8
III.1. Global Software Development................................................................................. 8III.2. Tecnologías de Comunicación................................................................................10
III.2.1. Cliente/Servidor.............................................................................................. 11III.2.1.1. WebServices............................................................................................ 11III.2.1.2. WebDAV................................................................................................. 12
III.2.2. Sistemas Distribuidos..................................................................................... 14III.2.2.1. JavaGroups.............................................................................................. 14III.2.2.2. JXTA........................................................................................................16
III.3. Ambientes de Desarrollo........................................................................................ 18III.3.1. Eclipse............................................................................................................. 18
III.3.1.1. Arquitectura de Eclipse........................................................................... 22IV. Requerimientos de Zerankwa......................................................................................... 26
IV.1. Requerimientos de Sistemas Distribuidos............................................................. 26IV.2. Requerimientos de la plataforma colaborativa...................................................... 26
V. Diseño e Implementación de Zerankwa.......................................................................... 30V.1. Arquitectura de Zerankwa........................................................................................30V.2. Implementación de Zerankwa..................................................................................32
V.2.1. co.edu.uniandes.zerankwa.gui.......................................................................... 33V.2.2. co.edu.uniandes.zerankwa................................................................................ 35
VI. Evaluación...................................................................................................................... 38VI.1. Eclipse y SWT........................................................................................................ 38VI.2. JXTA....................................................................................................................... 39
VII. Conclusiones y trabajos futuros....................................................................................40VIII. Bibliografía.................................................................................................................. 42IX. Anexo 1: Common Public License v 1.0........................................................................45X. Anexo 2: Imágenes de la Interfaz gráfica........................................................................52XI. Anexo 3: Diagramas de Clases: co.edu.uniandes.zeranwka.gui.................................... 56XII. Anexo 4: Diagramas de Clases: co.uniandes.zerankwa................................................57
3
ISC-2003-2-32
Lista de FigurasFigura II.1Arquitecutra JavaGroups[2]................................................................................ 15Figura II.2 Tipos de Pipes en JXTA[3]................................................................................ 17Figura II.3 Arquitectura de JXTA[3]....................................................................................18Figura II.4 Arquitectura Eclipse[1]...................................................................................... 23Figura II.5Arquitectura del Workbench............................................................................... 25Figura IV.1 Arquitectura Zerankwa..................................................................................... 30Figura IX.1Vista de Grupos y Usuarios............................................................................... 52Figura IX.2Vista de Mensajes.............................................................................................. 53Figura IX.3Página de Preferencias....................................................................................... 54Figura IX.4Página de Propiedades del proyecto.................................................................. 55Figura X.1 Diagrama de Paquetes Zerankwa UI.................................................................. 56Figura XI.1 Diagrama de Clases Zerankwa Core.................................................................57Figura XI.2 Diagrama de Clases del Paquete jxta.jaas........................................................ 58
4
ISC-2003-2-32
A mis dos familiasla de sangre y la de espíritu
que me han apoyado en todo momento
5
ISC-2003-2-32
I. Introducción
En los últimos años el desarrollo de software ha experimentado muchos cambios, uno deellos es la globalización de los grupos de desarrollo o Global Software Development. Estefenómeno ha venido creando nuevos retos dentro del campo de la ingeniería de softwaredebido a que cada vez se hace más importante encontrar vías para minimizar losproblemas relacionados con diferencias temporales, geográficas y culturales en esta nuevamanera de hacer software al interior de los grupos de trabajo. Estas dificultades sepresentan en todas las fases del desarrollo (desde la etapa de diseño hasta el proceso dedepuración y pruebas) y su causa principal es la falta de comunicación entre los distintosmiembros del equipo. Estas fallas se hacen particularmente evidentes durante laimplementación, donde problemas como dudas acerca de detalles de codificación odificultades en la configuración del ambiente de trabajo, puden durar horas e incluso díasen 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 demensajería instantánea o por medio del correo electrónico, pero es claro que estasaplicaciones no son suficientes ya que no brindan los elementos sincrónicos necesariospara la solución a estos y otros problemas que se presentan con regularidad durante lasdiferentes etapas del desarrollo.
Teniendo en cuenta esta problemática, se ve la necesidad de crear una plataforma dedesarrollo que permita llevar a cabo las tareas de programar, probar y depuraraplicaciones de manera colaborativa y sincrónica, compartiendo archivos de códigofuente y haciendo modificaciones simultáneas sobre estos. La construcción de dichaplataforma puede tomar como punto de partida alguno de los IDE's disponibles en elmercado, 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
ISC-2003-2-32
los cuales pueden ser construidas herramientas con las características de sincronismo ycolaboració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 laposibilidad de compartir de manera sincrónica los recursos de un proyecto de softwaredentro del IDE. Estos recursos pueden ser código Java o archivos de configuración quepueden 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 yrecepción de mensajes a través de un servicio de mensajería instantánea y facilidades parala integración con otras herramientas de la organización que brinden la funcionalidad deplaneació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 acercadel GSD (Global Software Development) y el estado del arte de varias tecnologías decomunicación que pueden ser utilizadas para la implementación de sistemas de desarrollocolaborativo 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: “Elestado donde puedes hablar con todo”
7
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 desoftware distribuido o global), las distintas tecnologías de comunicación existentes en laactualidad para la implementación de sistemas con algún grado de distribución y ladescripció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 desoftware 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 losgrupos de trabajo se debe principalmente al rápido crecimiento que ha tenido la industriaen los últimos años y que les ha permitido a las empresas llevar a sus equipos más allá delas fronteras de sus países para volverse más competitivas a nivel global; y a los avanceshechos en la infraestructura de las telecomunicaciones que hacen más fácil lacomunicación entre sitios geográficamente distantes.
Algunas de las ventajas que presenta este esquema sobre la manera tradicional deestablecer 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 yhabilidades de sus miembros y la disponibilidad de la mano de obra local. Losgrupos distribuidos superan esta limitación por la búsqueda de personas con talentosno 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 dedesarrollo en el mismo lugar(país) donde se encuentra el cliente.
8
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 turnoa las 6 es “relevado” por otro en India que esta iniciando su labor de trabajo del díasiguiente.
✔ 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 enotras 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 alinterior de los grupos de desarrollo de software. Paralelo a esto, la falta deencuentros persona-persona dificulta la creación de lazos de confianza que facilitenla comunicación de los miembros del grupo, pues a pesar de que existanherramientas como los sistemas de mensajeria instantánea, muchas personasencuentran 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, puesla existencia de interdependencias generan demoras y bajas en el desempeño delgrupo. Además se hace importante tener un control de las tareas y errores para poderidentificar 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 malentendidosque 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 uotros medios electrónicos, lo que entorpece la evolución de ciertas tareas delproceso de desarrollo. Por ejemplo, en la etapa de diseño son muy importantes lasdiscusiones y acuerdos hechos sobre la arquitectura del proyecto.
9
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 posibleque 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 ysistemas de control de proyecto de la organización.
La efectividad de este tipo de grupo de desarrollo se puede ver claramente en varios de losproyectos de código abierto como Linux, Apache, Posgresql, Eclipse, Mozilla entre otros,que están compuestos por desarrolladores que trabajan voluntariamente en ellos y sedistribuyen en varios países alrededor del mundo. Cabe aclarar que teniendo en cuenta lasdificultades 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 lacomunicación y coordinación de los distintos miembros del equipo.
Actualmente existen varias iniciativas como D-UML[18], una herramienta que permiterealizar diagramas de clases de manera distribuida, Palantir[17], una aplicación quepermite conocer los cambios y el impacto de estos sobre un proyecto de software yMILOS[11], un sistema que provee funcionalidades de workflow y control de errores queayudan a minimizar el impacto de los problemas mencionados al interior de los grupos detrabajo distribuido.
Aún hay mucho por investigar en este campo, siendo necesario establecer cuáles son lasmetodologías más adecuadas para estos grupos de trabajo, cuáles son las tecnologías yarquitecturas 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ónentre aplicaciones distribuidas. Esta diversidad dificulta la tarea de seleccionar en un
10
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 acontinuación se explican en detalle.
III.2.1. Cliente/Servidor
Las arquitecturas cliente/servidor y las ahora llamadas arquitecturas multinivel son labase de la mayoría de los sistemas distribuidos que existen en la actualidad, losWebServices y WebDAV son algunas de las tecnologías que soportan estos sistemas. Acontinuació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 enInternet como dentro de una Intranet. Su propósito principal es facilitar la integración dediversas aplicaciones tanto dentro de la organización como fuera de ella, pueden operar deuna manera bajamente acoplada, es decir, sus componentes pueden ser cambiadosfácilmente en tiempo de ejecución. Gracias a que los Web Services se describen a simismos mediante el archivo WDSL(Web Services Description Language), y sonpublicados dentro de servidores de registro UDDI (Universal Discovery, Description andIntegration), 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 requerimientosfuncionales; ahora también se tiene que pensar en la manera en que dicha aplicaciónpuede 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 llamadoSOAP (Simple Object Access Protocol), que define de manera estándar el esquema en quese hacen los requerimientos a uno de estos servicios y la forma en que estos debenretornar los mensajes. De esta manera se logra desacoplar los lenguajes de
11
ISC-2003-2-32
implementación y comunicación, facilitando la tarea de integrar aplicacionesdesarrolladas en diferentes plataformas y lenguajes. Debido a que existe un amplia gamade 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ásfá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 delprotocolo HTTP desarrollada alrededor de 1996 por la IETF2 y que es especificado en elRFC2518[6], que pretende hacer de la Web un medio escribible, permitiendo que variasaplicaciones puedan interoperar a través de HTTP mediante el intercambio de diferentestipos de recursos, que no necesariamente son archivos planos como HTML y XML.
WebDAV define un conjunto de nuevos encabezados y métodos que facilitan lanavegación y el mantenimiento de sitios Web, estos nuevos métodos permiten lamanipulación de Properties (Méta-información sobre los recursos almacenados en elservidor) y Collections (Conjuntos de recursos [Directorios]), controlar el acceso arecursos que se encuentren en uso y además heredar todas las ventajas de la estructuraHTTP/HTTPS, como la autenticación, la encripción y la navegación a través de Firewallsy Proxies. A diferencia de los métodos tradicionales de HTTP, los métodos de WebDAVposeen un cuerpo XML, esto para darle flexibilidad al protocolo y poder hacer variasoperaciones con un solo requerimiento. Los nuevos encabezados y métodos especificadospor 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
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 protegidoscon 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 delcandado 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 existapreviamente 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 olvideeliminar 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
ISC-2003-2-32
➔ MKCOL: Permite crear un directorio dentro del servidor.
Paralelo a WebDAV, la IETF ha estado desarrollando otras extensiones a HTTP comoDeltaV (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 quese puede usar en cualquier contexto. La aceptación que ha tenido WebDAV en la industria es muy amplia, lo que se refleja enla gran cantidad de aplicaciones que actualmente implementan esta especificación, comoMicrosoft 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 porvarias 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 deprogramación Java.
III.2.2.1. JavaGroups
JavaGroups[2] es un toolkit para diseñar aplicaciones que necesitan un medio decomunicación confiable. Los procesos que se comuniquen por medio de JavaGroupspueden crear grupos, enviar y recibir mensajes y ser notificados de cuándo un miembroentra o sale. Para hacer uso de JavaGroups, la aplicación puede usar directamente el APIdel Canal o utilizar los diferentes Building Blocks que provee el framework, los cuales sonabstracciones de más alto nivel que están construidas sobre el canal. Un ejemplo son lasTablas de Hash Distribuidas. Esta estructura se puede ver más claramente en la siguientefigura.
3 Access Control Protocol4 DAV Searching and Locating
14
ISC-2003-2-32
Los canales pueden ser configurados para que usen una pila de protocolos determinada, loque da al desarrollador la flexibilidad de seleccionar los servicios que son necesarios parasu aplicación. Los protocolos disponibles en JavaGroups para configurar el canal son:
UDP Permite usar IP multicast para enviar mensajes a losdiferentes miembros del grupo.
PING Usa IP multicast para encontrar a los demás miembros delgrupo en el momento de creación del canal.
MERGE2 Permite unir subgrupos en uno solo grupo.FD_SOCK Permite la detección de fallas basada en sockets. Genera una
notificación si un miembro falla.VERIFY_SUSPECT Permite hacer una doble verificación acerca de la posible falla
de un miembro del grupo.pbcast.Stable Borra los mensajes que han sido vistos por todos los miembros
del grupo.pbcast.NAKACK Garantiza que todos los mensajes son recibidos. También hace
una verificación acerca del orden en que se envían y recibenlos mensajes (FIFO)
UNICAST Similar a NAKACK para mensajes unicast
15
Figura III.1Arquitecutra JavaGroups[2]
ISC-2003-2-32
FRAG Permite la fragmentación y reconstrucción de mensajes tantoen multicast como en unicast.
pbcast.GMS Permite llevar el control sobre los miembros del grupo.TCP Especifica el uso de TCP como mecanismo de comunicación.
Los mensajes multicast se simulan enviando varios mensajesmulticast.
TCPPING 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 lainteracción entre aplicaciones y servicios p2p6. Para lograr esto JXTA define un conjuntode protocolos basados en XML que permite la independencia del lenguaje, sistemaoperativo y tecnología de comunicación. Dichos protocolos definen los mecanimosmínimos necesarios para construir un sistema p2p, la manera en que se debe hacer eldescubrimiento de peers, grupos, servicios, la manera de comunicar y enrutar losmensajes 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 deservicios mínimos que debería tener cualquier implemetación de JXTA. Estosservicios son: PipeService, el encargado de manejar la manera en que se comunicanlos peers; MembershipService, que define la manera en que los peers pueden aplicar
5 Tabla basada en al documentación de JavaGroups [2]6 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
ISC-2003-2-32
para participar en un grupo; AccessService, que define la manera en que se limita ono el acceso a los recursos dentro de un grupo; DiscoveryService, que define lamanera 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 aotros 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, quepermite encadenar un punto de salida con varios puntos de entrada y unicastSecure,que permite la comunicación segura a través de TLS.
➔ 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 unadvertisement.
La manera en que cada uno de estos elementos se integran dentro JXTA se puede observara continuación:
17
Figura III.2 Tipos de Pipes en JXTA[3]
ISC-2003-2-32
En la actualidad el conjunto de protocolos definido por JXTA están siendo implementadosen diferentes lenguajes como: J2SE, J2ME, C, Objetive-C, Rubby, Python, SmallTalk,entre otros. La comunidad que existe alrededor de JXTA ha estado creando diferentesservicios y aplicaciones que le dan más versatilidad al uso de esta plataforma. Dentro deestos servicios hay varios interesantes como XML-RPC, SOAP y voIP. Esto demuestra lagran fuerza que ha estado tomando el proyecto y la gran variedad de aplicaciones que sepueden 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 deIBM©, OTI(Object Technology International) y otras compañías que querían desarrollaruna plataforma de código abierto que permitiera la integración entre diversasherramientas de desarrollo y que sirviera como una manera de capitalizar el desarrollo de
18
Figura III.3 Arquitectura de JXTA[3]
ISC-2003-2-32
herramientas en el lenguaje de programación Java. “Eclipse es un IDE para nada enparticular”[19], que define una funcionalidad básica sobre la cuál es posible implementarherramientas de desarrollo para varios lenguajes como Java, C/C++, HTM, XML, entreotros. Todo esto es posible porque Eclipse está diseñado para descubrir, integrar y correrdistintos módulos(plug-ins) que le dicen a la plataforma cuáles son las acciones que debellevar 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 sourceque trabajan en él[20].
Como ambiente de desarrollo en Java, Eclipse provee al desarrollador de varias utilidadesque 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 desintaxis, marcadores, revisión de sintaxis, etc.; un depurador y un esquema sencillo deintegración con Ant y Junit. Todo este conjunto de características hace que la labor decodificación sea más sencilla para el desarrollador de Java, permitiéndole tener todas lasherramientas para su trabajo en una sola aplicación.
Como plataforma de integración, la arquitectura de Eclipse permite a los desarrolladoresextender fácilmente las funcionalidades del IDE, esto a través de varios Frameworks yAPIS, que hacen más fácil la interacción con la plataforma. Eclipse permite integrarvarias herramientas dentro de sí, esto lo libra de la limitación de una metodología detrabajo particular, permite desarrollar fácilmente aplicaciones con Internacionalización yen algunos sistemas operativos, se integra con aplicaciones y tecnologías como elreconocimiento de voz que lo hacen una aplicación accesible a una amplia gama deusuarios.
Como comunidad de código abierto, “la misión del proyecto Eclipse es adaptar ydesarrollar la tecnología de Eclipse para satisfacer las necesidades de la comunidad dedesarrolladores y de usuarios”[1]. Eclipse provee varias herramientas para que lacolaboración entre los distintos miembros de la comunidad (corporaciones, investigadoresy desarrolladores en general) puedan desarrollar herramientas inter-operables.
19
ISC-2003-2-32
El desarrollo de Eclipse está dividido en varios proyectos, cada uno de ellos con uncomité propio (PMCs, Project Management Committees) que coordina su evolución y queadministra las listas de correo, sistemas de control de errores y versiones que facilitan lacolaboració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 ayudasincluyen la interfaz del workbench, SWT y la infraestructura de integracióncon 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 plug-ins pueden ser extendidos para facilitar el desarrollo de otros sistemas másespecializados.
➢ 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 deeditores de UML, WYSIWYG para HTML, etc.
➢ COBOL: IDE para desarrollo de aplicaciones en COBOL.
20
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 transformarfácilmente los modelos de clases en código Java. También permite representarlos objetos como documentos XML.
➢ VE (Eclipse Visual Editor): Es un framework para crear editores de GUI
(Graphical User Interface). Incluye implementaciones de referencia paraSwing/JFC, pero pretende definir la arquitectura para construir herramientasde 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 serexploraciones 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 OrientedSoftware 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 otrosambientes 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
ISC-2003-2-32
proyecto se enfoca en la organización dinámica de programas y lacoordinació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 enmodelos.
➔ Eclipse Web Tools Platform Project: Este proyecto pretende desarrollar
herramientas que permitan a los desarrolladores crear aplicaciones Web que sepuedan integrar fácilmente con cualquier servidor que implemente la especificaciónde J2EE.
La licencia bajo la cuál se distribuye la mayor parte del código de Eclipse es la CommonPublic Licence (Ver anexo 1), que permite a los desarrolladores el uso comercial desoftware y la libre redistribución del código fuente del mismo. La ventaja de estaaproximación en la distribución del software es que impulsa la evolución del mismoporque 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 deEclipse fue guiado desde el principio por la extensibilidad. La manera en que se definennuevas funcionalidades para la plataforma es a través de los plug-ins (un plug-in es lamínima unidad funcional que reconoce Eclipse). Uno puede construir herramientas apartir de uno o más plug-ins. La manera en que estos plug-ins se integran a Eclipse es pormedio de los puntos de extensión (extension points). Cada punto de extensión es un lugardonde el desarrollador puede extender la plataforma (u otro plug-in que este instalado
22
ISC-2003-2-32
dentro de ella) y define la información que necesita para manejar las contribuciones quese 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 quecontiene toda la información que se necesita para poder instanciar un plug-in, define susdependencias, los nuevos puntos de extensión que el plug-in provee, y las extensiones ocontribuciones a puntos de extensión de la plataforma u otros plug-ins. La manera en queeste archivo es usado por la plataforma es la siguiente: Al iniciarse Eclipse la plataformadescubre y carga la información de los descriptores de cada plug-in y crea en memoria elregistro de plug-ins; con esta información la plataforma puede iniciarse rápidamente puesno necesita cargar cada plug-in para descubrir su funcionalidad, de hecho, un plug-in sólose carga en el instante que se requieren sus funcionalidades.
La arquitectura de Eclipse esta formada por varios componentes:
✔ 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, leerlos descriptores y construir el registro de plug-ins.
23
Figura III.4 Arquitectura Eclipse[1]
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 unproyecto, que está compuesto de directorios y archivos. Cada proyecto puede teneruna o más "naturalezas" (natures), que definen el tipo de recursos que contiene elproyecto. Por ejemplo, todos los proyectos Java tienen la "Java Nature".Adicionalmente el Workspace administra el mecanismo que mantiene el historial demodificaciones sobre los recursos y administra el sistema de "marcadores" quesirven para almacenar diferentes anotaciones sobre los recursos, como errores decompilació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 yperspectivas que constituyen la UI de Eclipse. La implementación del workbenchestá construida sobre dos toolkits SWT y JFace. SWT es el conjunto de widgets queestá integrada con el sistema operativo, lo que facilita la integración de Eclipse conel ambiente que los usuarios están acostumbrados.
JFace es un toolkit que está construido sobre SWT, provee los registros deimágenes, fuentes y preferencias, define interfaces de alto nivel para el manejo deeventos (actions) y "viewers" que facilitan la representación de los datos en widgetsde alto nivel como listas, tablas y árboles.
24
ISC-2003-2-32
✔ 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 deversiones, 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 losdesarrolladores.
25
Figura III.5Arquitectura delWorkbench
ISC-2003-2-32
IV. Requerimientos de Zerankwa
Zerankwa es una plataforma de edición colaborativa de software dentro de Eclipse. Losrequerimientos de este plug-in se dividen en dos grupos: Los requerimientos inherentes alos sistemas distribuidos y los requerimientos que brindan las funcionalidades decolaboración.
IV.1. Requerimientos de Sistemas Distribuidos
Los servicios mínimos que toda aplicación distribuida (incluyendo a Zerankwa) debebrindar 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 lospuertos 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
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 siestá 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 archivomostrado por el editor, y el otro debe poder observar los cambios de manerasincró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 conjuntamentelos mensajes de depuración que se muestren en ella.
Es importante precesisar que la implementación de estos requerimientos sobre el API deJXTA implica algunos refinamientos, entre ellos:
➢ Configuración de la red y de usuario:
En Zerankwa se pueden definir dos tipos de redes:
27
ISC-2003-2-32
1. Red de colaboradores segura: Una red de colaboradores segura se define comouna red JXTA en la que por lo menos existe un Rendezvous especial que proveelas funcionalidades de creación de grupos de trabajo y autenticación. Delmismo modo tiene la capacidad de interactuar con otras aplicaciones queproveen servicios dentro de la organización como herramientas de seguimientode Tareas, Servidores de Usuarios, entre otros.
2. Red de colaboradores pública: Una red de colaboradores publica es una red ad-hoc 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 gruposJXTA seguros, que garanticen la privacidad de los recursos que se compartendentro 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 (losque 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 losusuarios.
✔ 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 debeespecificar 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 usuariopodrá escoger entre enviar un mensaje instantáneo o hacer un requerimiento paracompartir el editor que se encuentre abierto actualmente; en este caso también se debepoder especificar si se desea que el colaborador pueda o no abrir más archivos que élseleccionado.
28
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 decolaboración. En caso de que haya pasado un tiempo considerable sin ningún tipo deinteracción entre los participantes de la sesión, el control del archivo debe volverinvariablemente al propietario del archivo.
29
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 semostrará un descripción de la arquitectura del plug-in, cuáles son los componentes queinteractú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 sediscutirán los pormenores de su implementación.
V.1. Arquitectura de Zerankwa
Zerankwa esta dividido en tres grandes componentes:
➔ Zerankwa UI (Interfaz gráfica): Es el encargado de brindar la visualización de los
30
Figura V.1 Arquitectura Zerankwa
ISC-2003-2-32
distintos elementos que interactúan dentro de la plataforma como grupos, usuarios ymensajes, 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 reflejadosen 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 anexo2).
✔ 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->Preferencesde Eclipse. Permite configurar los rendezvous y relays usados por JXTA pararealizar 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 Propertiesen un proyecto Java dentro del navigator de Eclipse. Aquí se configura y/o crea elgrupo habilitado para compartir los recursos de ese proyecto (Ver figura 4 del anexo2).
✔ Extensiones al menú desplegable de Eclipse: Estas opciones permiten configurar,
iniciar y desactivar a Zerankwa para un proyecto de Eclipse (Ver figura 5 del anexo2).
✔ 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 enuna 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 plataformade comunicación. Define el punto de extensión del plug-in y los servicios que brinda laplataforma.
7 Java Development Tool, plug-in que provee las funcionalidades de un IDE de Java,
31
ISC-2003-2-32
El punto de extensión definido por el plug-in es communicator, que define los serviciosbásicos que debe tener la implementación de Zerankwa sobre cualquier plataforma decomunicació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 paraimplementar 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) yco.edu.uniandes.zerankwa (Zeranwka Core), que se distribuyen juntos por medio de unFeature8. Los detalles de la implementación de estos plug-ins, será mostrada acontinuación.
8 Una de las esquemas que provee eclipse para distribuir varios plug-ins interdependientes de maneraagrupada.
32
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 yestá 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étodosutilitarios 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 usadaspor 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 dediá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 larealización de una tarea.
✔ LoadServersOperation: Clase que implementa el monitor que da la
33
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 esquemapropuesto 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
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 puntode extensión que puede ser usado para implementar la misma funcionalidad con unatecnologí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 debeimplementar 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 deextensió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. Lasprincipales 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
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 JXTAsobre 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 quedebe proveer un servicio de autenticación de usuarios a nivel de grupo dentro deJXTA.
✔ 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 estandary fácilmente extendible con la cual el plug-in se pudiera integrar con los otros sistemasdentro de una organización. Se escogió JAAS debido a su versatilidad, porque hacefácil la labor de cambiar el mecanismo de autenticación sin necesidad de cambiar todala aplicación, y por que hace sencilla la integración con nuevos esquemas deautenticación y autorización de los usuarios.
La configuración de la autenticación usando JAAS se hace por medio del archivoJxtaConfig.xml que especifica las siguientes propiedades:
9 Java Authentication and Authorization Service
36
ISC-2003-2-32
El papel de cada uno de estos tags en la configuración del método de autenticación seexplica 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 uopcional. Para que un usuario sea autenticado debe lograr autenticarse con todoslos LoginModule que tengan especificado el controlFlag requerido.
➢ Services: Permite configurar si la plataforma permite la búsqueda de servidores
rendezvous y relay remotos.
37
<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>
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 lautilizació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'sespecializados, que reducen la cantidad de código que se tiene que escribir paradesarrollar una funcionalidad. En general, desarrollar sobre Eclipse es sencillo, ladocumentación que viene con la plataforma en la mayoría de los casos es suficiente parasolucionar las dudas que aparecen durante la implementación, aunque hay muchas otrasque no son obvias y hacen necesaria la inspección del código de la plataforma. Tambiénson muy útiles los artículos que se encuentran en el sitio de Eclipse[1], y en general son elmejor 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 losdesarrolladores 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 deejecución, difieren enormemente con la manera tradicional de desarrollar aplicacionesgrá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 muysimilar a crear una tabla HTML. Otros como el manejo de imágenes, en SWT es necesarioliberar las imágenes cuando no se esta mostrando el componente, obligan al desarrolladora estar pendiente de aspectos con los que usualmente no tiene que tratar. Lo mismo pasacon el manejo de los threads de ejecución que están encargados de mostrar los elementosgráficos, para hacer una actualización sobre un objeto es necesario hacer mucho máscódigo (esto depende del API que este usuando, JFace facilita muchas cosas, pero no sepuede usar siempre), y puede ser un dolor de cabeza para un desarrollador pocoexpermientado en este API. Para desarrollar los aspectos gráficos dentro de Eclipse es
38
ISC-2003-2-32
recomendable usar JFace en lugar de SWT en la medida de lo posible, este API encapsulavarios de los aspectos “problemáticos” del desarrollo con SWT.
En resumen, desarrollar para Eclipse es una tarea relativamente sencilla, debido a lasfácilidades que da la manera en que éste está construido. La mayor parte de losinconvenientes que se pueden presentar son debidos a la integración con el workbench queimplica la utilización de SWT.
Con base en la experiencia ganada en el desarrollo de este proyecto, se recomienda seguirlos siguientes pasos en caso de encontrar dudas durante el desarrollo de herramientas paraEclipse:
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 lacomunicación en un ambiente p2p, al ser básicamente una especificación más que unframework, 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 deservicios sobre él es relativamente sencillo y gracias a que es un proyecto de códigoabierto, existen varias iniciativas interesantes que se pueden consultar en el sitio delproyecto[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 fueusado en Zerankwa para el llamado remoto de las acciones necesarias para mostrar loscambios en el workbench.
Una de la mayores dificultades en la trabajo con JXTA fue la de garantizar la presencia de
39
ISC-2003-2-32
los otros usuarios, esto debido a que no existe (o no esta debidamente documentado) unservicio sobre JXTA que permita monitorear el estado de la conexión con los otrosusuarios. Otro aspecto difícil de manejar fueron los caches, estos juegan un papelfundamental dentro de JXTA, pues ayudan a minimizar el tráfico de la red, pero puedenllegar a ser un dolor de cabeza, cuando se necesita garantizar la existencia de un mismorecurso en una red tan variable como la p2p. En Zerankwa esto fue una gran dificultadpues en este tipo de aplicación era necesario que el grupo en que estuvieran trabajando losusuarios fuera el mismo, y si la caducidad de los caches no era la adecuada, se podríancrear 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 desarrollaraplicaciones distribuidas de mediana complejidad. Su flexibilidad permite a los usuariosconstruir sobre ella aquellos servicios que se consideren interesantes.
VII. Conclusiones y trabajos futuros
Dentro del contexto del Global Software Development, la necesidad de herramientas quefáciliten el trabajo de grupos de desarrollo distribuidos es algo latente. Zerankwa comoplataforma de trabajo colaborativo sobre Eclipse, pretende solucionar uno de estosaspectos, en especial, la solución rápida de problemas encontrados durante la fase decodificación.
El desarrollo de Zerankwa permitió explorar varias tecnologías para la implementaciónde aplicaciones que solucionen estos problemas. En particular permtió evaluar laviabilidad del desarrollo de herramientas colaborativas dentro de Eclipse y el impacto delesquema de comunicaciones p2p en el desarrollo de aplicaciones distribuidas.
Eclipse como proyecto de código abierto es un excelente punto de partida para eldesarrollo de diferentes herramientas que asistan la labor del desarrollador, ya sean estassincrónicas o asincrónicas. La madurez y robustez de su diseño permite que eldesarrollador se enfoque únicamente en los aspectos relevantes de su herramienta, y lo
40
ISC-2003-2-32
convierte en una buena alternativa para la implementación de aplicaciones de trabajocolaborativo.
Por su parte JXTA, como especificación y plataforma de desarrollo para aplicaciones p2pestá todavia en sus inicios, sin embargo está tomando mucha fuerza. Su independencia dellenguaje de programación y la gran cantidad de desarrolladores que trabajan en elproyecto lo hacen una buena elección para la implementación de este tipo. Trabajar conJXTA simplifica al desarrollador muchas de las labores típicas de los sistemasdistribuidos. Para poder evaluar correctamente el desempeño de JXTA en laimplementación de sistemas p2p es necesario buscar iniciativas similares e implementaraplicaciones sobre ellas.
Futuros trabajos basados sobre Zerankwa podrian ser extensiones del plug-inimplementadas sobre otras tecnologías de comunicación, no necesariamente p2p, quepermitan evaluar cuales son los aspectos críticos a tener en cuenta en el desarrollo deaplicaciones de trabajo colaborativo. También se podría extender las funcionalidades deZerankwa implementando servicios como la comunicación de voz sobre IP, o video, parahacer la comunicación mas interactiva, ayudando de esta manera a fortalecer los lazos deconfianza entre los miembros del equipo. Otro aspecto a tener en cuenta es mejorar lascapacidades del plug-in para integrarse con otras herramientas que apoyen el trabajo degrupos distribuidos.
41
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 Systemsbased en WebDAV
http://nestroy.wi-inf.uni-essen.de/Forschung/Publikationen/WETICE99/webdav-
42
ISC-2003-2-32
client-impl/
[11] 2003, Bowen Seth. Using a P2P Architecture to Support Distributed SoftwareDevelopment
http://sern.ucalgary.ca/~milos/papers/2003/Bowen2003.pdf
[12] De Souza, Basaveswara,Redmiles.Supporting Global Software Development withEvent Notification Servers
http://www.cis.ohio-state.edu/~nsridhar/ICSE02/GSD/PDF/Desouza.pdf
[13] Atkins, Handel, Hersbleb, Mockus, Perry, Wills. Global Software Development: TheBell Labs Collaboratory
http://www.cs.uoregon.edu/~datkins/papers/icse-collab.pdf
[14] Kotlarsky, Kumar, Hillegersberg. Coordination and Collaboration for GlobalDistributed Teams: The Case of Component-Based/Object-Oriented SoftwareDevelopment
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 SoftwareDevelopment
http://www.ics.uci.edu/~andre/research/papers/IWGSD2002.pdf
[18] Boulila, Dutoi, Brügge. D-Metting: an Object-Oriented Framework for SupportingDistributed Modeling of Softwarehttp://wwwbruegge.in.tum.de/publications/includes/pub/boulila2003dmeeting/boulila2003dmeeting.pdf
43
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 DevelopersGuide 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
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 documentationdistributed 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 aredistributed by that particular Contributor. A Contribution 'originates' from aContributor if it was added to the Program by such Contributor itself oranyone acting on such Contributor's behalf. Contributions do not includeadditions to the Program which: (i) are separate modules of softwaredistributed in conjunction with the Program under their own licenseagreement, 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 necessarilyinfringed 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 allContributors.
2. GRANT OF RIGHTS
a) Subject to the terms of this Agreement, each Contributor hereby grants
45
ISC-2003-2-32
Recipient a non-exclusive, worldwide, royalty-free copyright license toreproduce, prepare derivative works of, publicly display, publicly perform,distribute and sublicense the Contribution of such Contributor, if any, andsuch derivative works, in source code and object code form.
b) Subject to the terms of this Agreement, each Contributor hereby grantsRecipient a non-exclusive, worldwide, royalty-free patent license underLicensed Patents to make, use, sell, offer to sell, import and otherwise transferthe Contribution of such Contributor, if any, in source code and object codeform. This patent license shall apply to the combination of the Contributionand the Program if, at the time the Contribution is added by the Contributor,such addition of the Contribution causes such combination to be covered bythe Licensed Patents. The patent license shall not apply to any othercombinations which include the Contribution. No hardware per se is licensedhereunder.
c) Recipient understands that although each Contributor grants the licenses toits Contributions set forth herein, no assurances are provided by anyContributor that the Program does not infringe the patent or other intellectualproperty rights of any other entity. Each Contributor disclaims any liability toRecipient for claims brought by any other entity based on infringement ofintellectual property rights or otherwise. As a condition to exercising therights and licenses granted hereunder, each Recipient hereby assumes soleresponsibility to secure any other intellectual property rights needed, if any.For example, if a third party patent license is required to allow Recipient todistribute the Program, it is Recipient's responsibility to acquire that licensebefore distributing the Program.
d) Each Contributor represents that to its knowledge it has sufficient copyrightrights in its Contribution, if any, to grant the copyright license set forth in thisAgreement.
46
ISC-2003-2-32
3. REQUIREMENTS
A Contributor may choose to distribute the Program in object code form under its ownlicense 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 andconditions, express and implied, including warranties or conditions of title andnon-infringement, and implied warranties or conditions of merchantabilityand 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, suchas lost profits;
iii) states that any provisions which differ from this Agreement are offered bythat 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 amedium 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 amanner that reasonably allows subsequent Recipients to identify the originator of the
47
ISC-2003-2-32
Contribution.
4. COMMERCIAL DISTRIBUTION
Commercial distributors of software may accept certain responsibilities with respect toend users, business partners and the like. While this license is intended to facilitate thecommercial use of the Program, the Contributor who includes the Program in acommercial product offering should do so in a manner which does not create potentialliability for other Contributors. Therefore, if a Contributor includes the Program in acommercial product offering, such Contributor ("Commercial Contributor") hereby agreesto defend and indemnify every other Contributor ("Indemnified Contributor") against anylosses, damages and costs (collectively "Losses") arising from claims, lawsuits and otherlegal actions brought by a third party against the Indemnified Contributor to the extentcaused by the acts or omissions of such Commercial Contributor in connection with itsdistribution of the Program in a commercial product offering. The obligations in thissection do not apply to any claims or Losses relating to any actual or alleged intellectualproperty infringement. In order to qualify, an Indemnified Contributor must: a) promptlynotify the Commercial Contributor in writing of such claim, and b) allow the CommercialContributor to control, and cooperate with the Commercial Contributor in, the defense andany related settlement negotiations. The Indemnified Contributor may participate in anysuch claim at its own expense.
For example, a Contributor might include the Program in a commercial product offering,Product X. That Contributor is then a Commercial Contributor. If that CommercialContributor then makes performance claims, or offers warranties related to Product X,those performance claims and warranties are such Commercial Contributor'sresponsibility alone. Under this section, the Commercial Contributor would have todefend claims against the other Contributors related to those performance claims andwarranties, and if a court requires any other Contributor to pay any damages as a result,the Commercial Contributor must pay those damages.
5. NO WARRANTY
EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, THE PROGRAM IS
48
ISC-2003-2-32
PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OFANY KIND, EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT LIMITATION,ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT,MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each Recipientis solely responsible for determining the appropriateness of using and distributing theProgram and assumes all risks associated with its exercise of rights under this Agreement,including but not limited to the risks and costs of program errors, compliance withapplicable laws, damage to or loss of data, programs or equipment, and unavailability orinterruption of operations.
6. DISCLAIMER OF LIABILITY
EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, NEITHER RECIPIENTNOR ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY DIRECT,INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIALDAMAGES (INCLUDING WITHOUT LIMITATION LOST PROFITS), HOWEVERCAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)ARISING IN ANY WAY OUT OF THE USE OR DISTRIBUTION OF THE PROGRAMOR THE EXERCISE OF ANY RIGHTS GRANTED HEREUNDER, EVEN IF ADVISEDOF THE POSSIBILITY OF SUCH DAMAGES.
7. GENERAL
If any provision of this Agreement is invalid or unenforceable under applicable law, itshall not affect the validity or enforceability of the remainder of the terms of thisAgreement, and without further action by the parties hereto, such provision shall bereformed to the minimum extent necessary to make such provision valid and enforceable.
If Recipient institutes patent litigation against a Contributor with respect to a patentapplicable to software (including a cross-claim or counterclaim in a lawsuit), then anypatent licenses granted by that Contributor to such Recipient under this Agreement shallterminate as of the date such litigation is filed. In addition, if Recipient institutes patentlitigation against any entity (including a cross-claim or counterclaim in a lawsuit)
49
ISC-2003-2-32
alleging that the Program itself (excluding combinations of the Program with othersoftware or hardware) infringes such Recipient's patent(s), then such Recipient's rightsgranted under Section 2(b) shall terminate as of the date such litigation is filed.
All Recipient's rights under this Agreement shall terminate if it fails to comply with anyof the material terms or conditions of this Agreement and does not cure such failure in areasonable period of time after becoming aware of such noncompliance. If all Recipient'srights under this Agreement terminate, Recipient agrees to cease use and distribution ofthe Program as soon as reasonably practicable. However, Recipient's obligations underthis Agreement and any licenses granted by Recipient relating to the Program shallcontinue and survive.
Everyone is permitted to copy and distribute copies of this Agreement, but in order toavoid inconsistency the Agreement is copyrighted and may only be modified in thefollowing manner. The Agreement Steward reserves the right to publish new versions(including revisions) of this Agreement from time to time. No one other than theAgreement Steward has the right to modify this Agreement. IBM is the initial AgreementSteward. IBM may assign the responsibility to serve as the Agreement Steward to asuitable separate entity. Each new version of the Agreement will be given a distinguishingversion number. The Program (including Contributions) may always be distributedsubject to the version of the Agreement under which it was received. In addition, after anew version of the Agreement is published, Contributor may elect to distribute theProgram (including its Contributions) under the new version. Except as expressly stated inSections 2(a) and 2(b) above, Recipient receives no rights or licenses to the intellectualproperty of any Contributor under this Agreement, whether expressly, by implication,estoppel or otherwise. All rights in the Program not expressly granted under thisAgreement are reserved.
This Agreement is governed by the laws of the State of New York and the intellectualproperty laws of the United States of America. No party to this Agreement will bring alegal action under this Agreement more than one year after the cause of action arose. Eachparty waives its rights to a jury trial in any resulting litigation.
50
ISC-2003-2-32
51
ISC-2003-2-32
X. Anexo 2: Imágenes de la Interfaz gráfica
52
Figura X.1Vista de Grupos y Usuarios
ISC-2003-2-32
53
Figura X.2Vista de Mensajes
ISC-2003-2-32
54
Figura X.3Página de Preferencias
ISC-2003-2-32
55
Figura X.4Página de Propiedades del proyecto
ISC-2003-2-32
XI. Anexo 3: Diagramas de Clases:
co.edu.uniandes.zeranwka.gui
56
Figura XI.1 Diagrama de Paquetes Zerankwa UI
ISC-2003-2-32
XII. Anexo 4: Diagramas de Clases:
co.uniandes.zerankwa
57
Figura XII.1 Diagrama de Clases Zerankwa Core
ISC-2003-2-32
58
Figura XII.2 Diagrama de Clases del Paquete jxta.jaas
