Informe Proyecto: Gestión de Bookmarks Rodrigo Guridi – Claudia Rostagnol – Gerardo Canedo Grupo 1-A Tsi3 - 2004 INCO - Facultad de Ingeniería - Universidad de la República Montevideo, Uruguay

Resumen— Se diseñó e implementó un sistema de almacenamiento y gestión de bookmarks centralizado para acceso a través de Internet. Su objetivo es permitir al usuario un manejo ágil y centralizado de sus bookmarks, así como permitir el intercambio de bookmarks entre usuarios, asegurando una mayor disponibilidad mediante un mecanismo de autenticación que tiene previsto el trabajo en distintos servidores de manera transparente.

Introducción El objetivo principal del sistema es el de administrar un repositorio de bookmaks de manera de que un usuario pueda acceder a él desde cualquier computadora conectada a Internet. Hay muchos aspectos adicionales que quisimos incorporar al sistema siendo los más destacables el intercambio de bookmarks entre los usuarios; un sistema, si bien no muy avanzado, de búsquedas altamente extensible y la posibilidad de logearse en servidores que pueden no ser los que tienen el repositorio de ese usuario, sino solamente estar asociados a éste para acceder a los bookmarks. La combinación de la primera y la ultima de esas características fueron las que tuvieron un mayor impacto en nuestro diseño. Desde un principio nos vimos obligados a manejar conceptos como permisos sobre un elemento para un determinado usuario o logeo remoto (que en nuestro caso no esta referido a la ubicación del cliente sino a la clase de cliente, ya que otro servidor puede estar en este momento supliendo a la habitual capa de presentación). Si bien tomamos en cuenta la performance de las distintas soluciones a la hora de diseñar nuestro sistema hubieron varios puntos en los cuales la exploración de las posibilidades de ciertas tecnologías tuvo una mayor influencia en el diseño que su escalabilidad o performance (el caso mas claro es el uso de CMP Entity Bean, dado que nuestro objetico se centró en probar su flexibilidad en un esquema principalmente recursivo). También decidimos utilizar Xdoclets para la generación de los archivo de configuración, que si bien tienen una gran productividad luego de comprenderlos, no están debidamente documentados y en algunos casos es necesario incluir información redundante para lograr los resultados buscados. Otra de las tecnologías que se evaluó fue Struts para la interfaz Web pero dado el momento relativamente tardío de la decisión y los pobres resultados obtenidos en una primera exploración decidimos que el costo beneficio de su uso no era conveniente. Se estudió un pluggin para eclipse que automatizara la genreación de Struts, facilitando el diseño de la interfaz web. La implementación con Struts Studio y Eclipse proporcionaba gran productividad a la hora de desarrollar, pero no ofrecía la compatibilidad necesaria para utilizarlo conjuntamente con el pluggin de J2EE (Lomboz). Además se encontraron dificultades a la hora de configurar JBOSS para el uso de esta tecnología y la información disponible al respecto era muy escasa.

Tecnologías Usadas Eclipse Eclipse es un proyecto de código libre, comenzado por IBM, para desarrollar una herramienta universal para desarrolladores. Una de las ventajas más vistosas de la plataforma de desarrollo Eclipse es la capacidad de ser extendida con funcionalidad provista por distintas herramientas, de diferentes proveedores, que se integran con el IDE a nivel de APIs. Eclipse es una herramienta abierta y universal de plataforma o herramienta base. “Abierta” significa que Eclipse es un proyecto de fuente abierta. “Universal” expresa que Eclipse usa una novedosa arquitectura plug-in que permite cercanas e infinitas extensiones a la base IDE. Estos plug-ins pueden hacer todo desde sintaxis hasta interfaz con un sistema de control de código fuente. La plataforma Eclipse misma está hecha de varios componentes mayores: la plataforma runtime, el espacio de trabajo, el workbench, el juego de herramientas estándar widget (SWT), la versión y administración de configuración (VCM) y el sistema de ayuda.

Lomboz Lomboz es un plugin diseñado para el entorno de desarrollo Eclipse con el fin de facilitar el desarrollo de aplicaciones J2EE. Emplea tecnología Open – Source como: Jasper, XDoclet, Axis y Ant. Soporta el ciclo de desarrollo completo: Desarrollo, deploy, testeo y debug. Por medio de este plugin se generan tanto las clases necesarias para el funcionamiento de la aplicación como los archivos necesarios para realizar un deploy correcto.

J2EE(Java 2 Enterprise Edition) Es una Standart para el desarrollo de aplicaciones orientada al desarrollo de aplicaciones web, aplicaciones distribuidas, y la nueva rama de tecnologías basadas en XML. Si bien su crecimiento ha sido tal que en muchas empresas se ha adoptado para el desarrollo de aplicaciones (especialmente web), esta compuesta por varias tecnologías que todavía están desarrollándose y algunas que han sido duramente cuestionadas (el ejemplo más claro son los CMP Entity Beans).

EJB(Enterprise Java Bean) Es uno de los componentes de J2EE, se divide en tres tipos de Beans: Entity Beans, Session Beans y Message Driven Beans. Son los encargados de funciones tan variadas como el manejo de la persistencia y el intercambio de mensajes entre aplicaciones. Los Enterprise Java Beans(EJB) son componentes del modelo de desarrollo de aplicaciones enterprise de Sun. Un Enterpise Java Bean es elemento de lógica o de persistencia, que acompañado de la presentación basade en tecnología Servlet+JSP forman lo que son los elementos java programables del modelo J2EE. Es importante notar que J2EE es una especificación, y no un producto particular.

Entity Beans Son los encargados de manejar la persistencia de los objetos de la aplicación. Existen dos tipos de Entity Beans, los Container Managed Persistence y los Bean Managed Persistence. El

primero tiene la particularidad de que genera todas las sentencias SQL necesarias para la persistencia de los objetos. Se configuran las principales características de los objetos (como ser el nombre de la tabla donde se guardan los datos, de las columnas que almacenan cada campo y las relaciones entre los distintos objetos) en archivos XML. En cambio en el segundo todo la generaron de las sentencias SQL para el manejo de la persistencia se realiza a mano por el programador. Para este proyecto se decidió utilizar la tecnología C.M.P., y probar su funcionamiento y performance con consultas sobre una estructura esencialmente recursiva.

Session Beans Se encargan de encapsular las operaciones que componen la logica del negocio he interactuan tanto con los Entity Beans para el manejo de la pesistencia como con los Message Beans. Pueden ser statefull, que les permite recordar las anteriores llamadas de un cliente al bean o stateless. Los Stateless Session Beans no mantienen estado en el EJB Container. Estos EJB's son utilizados para realizar tareas rutinarias que no requieren identificar o rastrear al cliente, algunos EJB's de este tipo son: operaciones matemáticas complejas, búsquedas generales, etc. Los Statefull Session Beans permiten mantener la sesión del cliente en el EJB Container, de esta manera el cliente puede trabajar con cierto juego de datos especifico administrado por el EJB Container.

XDoclets Es un lenguaje basado en atributos. Permite reducir el tiempo de desarrollo generando automáticamente los archivos XML necesarios para realizar el deploy, así como las clases asociadas a un bean (intefases locales y remotas, clases de claves compuestas, Value Objects, etc). Por medio de esta tecnología se mantienen sincronizadas las diferentes interfases de un bean. Se caracteriza por que un bean tiene asociada solamente un clase. Tambien brinda un marco de trabajo independiente del servidor de aplicaciones para el que se esté desarrollando, lo que minimiza el impacto ante un cambio del mismo. Esto es debido a que el mismo código XDoclet genera los diferentes archivos xml necesarios para configurar cada servidor de aplicaciones en particular. El mecanismo utilizado para obtener el resultado anteriormente mencionado es la inclusión de metadata (por medio de etiquetas Javadoc), tanto a nivel de clase como a nivel de método. Para generar los diferentes archivos, XDoclet analiza tanto la metadata ingresada como la estructura del archivo fuente (paquetes, clases, métodos, y campos). Utilizando esta información y los diferentes templates para los archivos que se desean generar; se consigue como resultado un conjunto de clases java y de archivos XML necesarios para realizar el deploy. Esto es especialmente importante cuando se decide utilizar Entity Beans del tipo CMP, pues XDoclet genera los mappings específicos de cada CMP/CMR. Lamentablemente en este último punto no existe actualmente una estandarización completa (es parcial) en los tags a utilizar, por lo cual cada servidor de aplicaciones necesita que se le indica información extra mediante tags propietarios.

Ejemplo de tag XDoclet de definicon de Entity Bean (CMP)

En el ejemplo anterior se puede ver como se utilizó XDoclets para definir el Entity Bean Bookmark. Este tag se utiliza a nivel de clase. Intuitivamente se puede deducir el significado de cada atributo. Por ejemplo el atributo JNDI-NAME indica el string con el cual sera asociado el Bean en el Name Service.

Ejemplo de tag XDoclet de definicon de un finder (CMP)

Para definir un Finder de un CMP Bean , tambien se utiliza un tag XDocket. Como atributos se destacan la firma del método y la sentencia QL. Es un tag a nivel de clase. Una de las principales ventajas es que dicho finder se define dentro del bean al que hace referencia, no en el archivo de configuración XML.

Ejemplo de tag XDoclet de definicon de un campo de un Entity Bean (CMP)

En cuanto a tags a nivel de métodos, se encuentran varios tags. El pricipal tag es el que indica si el método se verá reflejado en la interfaz local, remota o ambas. Para los Entity Beans del tipo CMP, existen varios tags que indican el nombre del campo que lo persiste, si es parte o no de la clave primaria, etc. Cabe destacar que de existir varios métodos con el tag @ejb.pk-field, se creará una clase Key para dicho entity.

Ejemplo de tag XDoclet de definicon deuna relacion en un Entity Bean (CMP)

En el ejemplo que muestra la sección de código superior se identifican los tags utilizados para indicar una relación entre dos Entity beans. Se distinguen tags Estandars, así como tags específicos del servidor de aplicaciones JBOSS. El primer tag especifica el nombre de la relación, el rol que cumple este Entity, y el nombre del rol del otro Entity asociado. Debe existir un tag en un método del Entity bean de destino (Bean Folder), con el mismo nombre de relación y los roles intercambiados. Sobre los tags específicos de JBOSS, debemos destacar que para cada servidor de aplicaciones existen un conjunto equivalente. Nada impide la coexistencia de los mismos. En el caso particular de JBOSS un tag que indica que se realiza chequeo de integridad referencial, el campó donde se almacena la referencia foránea y la clave en el bean de destino de la relación. La principal desventaja de esta tecnología es la escueta documentación existente. La curva de aprendizaje de la misma se ve afectada dado que el conocimiento de ésta se basa principalmente en un mecanismo de ensayo y error.

Arquitectura Uno de los principales objetivos de nuestro sistema es la interacción con otros servidores para ofrecer al usuario una interfaz que unifique los usuarios de todos los servidores para así poder intercambiar bookmarks, permitiendo además el acceso a un usuario (llamémosle U) de un servidor (llamémosle A) en otro servidor (llamémosle B) y que el servidor B se encargue de consultar y llevar a cabo las operaciones en el servidor A.

Usuario

Servidor

Servidor

Esta funcionalidad tuvo un enorme impacto en el diseño ya que debimos coordinar las funcionalidades que nuestros sistemas iban a ofrecer y el medio por el cual las ofrecerían.

Interacción entre servidores En el diseño de la arquitectura de la interacción entre servidores uno de los factores a los cuales prestamos mayor consideración fue la extensibilidad (y en menor grado la escalabilidad), para lo cual definimos entre los dos grupos una interfaz sencilla (la cual llamamos IServidor) y un conjunto de VO que nos permitieran comunicarnos con los servidores sin necesitar saber de ellos nada mas que su dirección IP, puerto y el JNDI que identifica a el objeto que implementa la interfaz en el servidor. Luego cada uno de los grupos implemento esta interfaz con total libertad. En nuestro caso decidimos que los objetos necesarios para implementar esa interfaz fueran parte de la lógica(a esa capa le llamamos capa Lógica Publica), pero a su vez definimos otra parte de la lógica que nos ayudaría a interactuar con los servidores (y a esa parte le llamamos capa Lógica Privada). Además separamos la capa de Presentación de ambas partes de la lógica mediante una capa intermedia(MultiServidor) que fundamentalmente se ocupa de redirigir los pedidos que el servidor local no puede responder y unificar los pedidos en los cuales intervienen más de un servidor. Por ultimo vale la pena aclarar que la logica si bien puede ser llamada por otros servidores nunca realiza llamados a otros servidores por si misma, y de manera inversa la capa MultiServidor redirige pero no recibe pedidos de otros servidores.

Capa de Presentación En la capa de interfaz puede encontrarse una arquitectura distribuida Cliente – Servidor. Tenemos un conjunto de servicios provistos por el servidor y un conjunto de clientes que requieren de dichos servicios. Tanto los clientes como el servidor son procesos lógicos. Para esta capa se tomó una decisión de diseño importante. Se aplicó el patrón de diseño Model – View - Controller para el manejo de la lógica de las paginas web. Se eligió este patrón no solo por las características de escalabilidad que presenta, sino también porque su comprensión representa un paso previo al uso del framework “struts”, quien se basa en este patrón para su arquitectura. En un principio se consideró la utilización de struts para el desarrollo de la aplicación, pero como esta decisión agregaba un alto riesgo al proyecto debido a la falta de experiencia de los participantes en su uso, la idea fue postergada para una próxima versión y se adopto el diseño basado en MVC que se puede apreciar en las Figuras

El patrón mencionado plantea la separación de responsabilidades en tres entes: Controller En este caso seria representado por un servlet View En este caso serian las JSP`s encargadas de generar las páginas html para enviar al browser Model Estaría representado por un conjunto de clases java que son las que entablan el diálogo con la capa lógica

1. Solicitud

Navegador

6. Resultado

Controller (Servlet)

2. Acciones 3. Resultados Model (JavaBeans y/o EJBs)

4. Redireccionamiento

View (JSPs, TagLibs)

5. Consulta

Estructura del patrón MVC

Como se puede apreciar en la Figura 5 El “View” es un conjunto de JSP´s agrupadas (no forman un paquete, se presentan de esta forma solo a los efectos de claridad). El “Controller” es un servlet conocido en la aplicación como “Servidor.java” y por último el “Model” es la lógica de negocios. Para este último se cuenta con un paquete de dos grupos de archivos, por un lado tenemos clases java que implementan la interfaz “Action” cuyas instancias serán las que realicen la lógica necesaria en cada pedido de servicio que llegue al Controller y JB`s para permitir el encapsulamiento y transporte de la información. La clase Interfaz.java sirve de nexo con la capa lógica, concentrando así la comunicación en un único punto y haciendo transparente a la capa de Presentación los cambios de la capa lógica.

Patrón MVC aplicado al producto

Otra decisión fue el uso del patrón de diseño Singleton en la capa de interfaz. El patrón Singleton permite asegurar que una clase tiene en todo momento de la ejecución una sola instancia y provee un punto de acceso global a ella. La capa de interfaz contiene una clase encargada de crear los objetos que realizan la interfaz “Action” y es la que llamamos “ActionFactory”. Es necesario asegurarse que esta clase siempre tenga una sola instancia y que dicha instancia sea fácilmente accesible.

Capa MultiServidor La capa multiservidor esta integrada por un único Statefull Session Bean encargado de redirigir los pedidos que el servidor local no puede resolver, para estas funciones se apoya tanto en la capa Lógica Privada que le proporciona operaciones para determinar a que servidor debe consultar y con que parámetros ubicarlo, como en la capa Lógica Publica que para el es tan solo una de las posibles implementaciones de la interfaz IServidor y a la cual accede para realizar las operaciones requeridas.

CapadePresentación

Servido r

CapaMultiServidor Capa Lógica

DBMS

Capa Lógica

Capa Lógica Pública (Interfaz externa) La capa Lógica Publica engloba la mayor parte de las funcionalidades del sistema para lo cual utiliza varios Entity Beans para manejar la persistencia de nuestras entidades y Stateless Sessions Beans para realizar la lógica de negocios asociadas a ellos. Además cuenta con Statefull Session Bean que es el que implementa la interfaz IServidor y se encarga de llamar a los métodos que estan implementados en los demas Session Beans. Las entidades que componen nuestro sistema son Bookmarks, Carpetas, Usuarios y Permisos (también servidores pero no están en esta capa).

Capa Lógica Privada La capa logica privada se encarga de proveer la capa MultiServidor de la información necesaria para consultar los servidor, principalmente información referente a la conexión que debe abrir (Host,puerto,JNDI name). Cuenta con un Entity Bean para mapear la entidad Servidor y un Stateless Session Bean que se encarga de encapsular la en este caso muy simple lógica de negocio relacionada.

Capa MultiServidor Capa Lógica Pública Statefull Session Bean IServidor

Stateless Session Beans User Manager Element Query

Capa Lógica Privada Stateless Session Bean Server Entity Bean

CMP Entity Beans User Permisos Folde

Bookmar

Referencias - Tutorial de Servlets y JSP Servlets and JavaServer Pages: A Tutorial

- JSP Implementations & Specification http://java.sun.com/products/jsp/download.html#specs

- Eclipse http://www.eclipse.org

- JBOSS http://www.jboss.org - MySQL http://www.mysql.org

- Lomboz http://sourceforge.net/projects/lomboz

- XDoclet http://xdoclet.sourceforge.net