DISEÑO Y DESARROLLO DE UN PORTLET PARA LA GESTIÓN DE CURSOS EN LIFERAY INTEGRADO CON EL SISTEMA DE GESTIÓN DE WORKFLOWS JBPM.

Transcripción

1 ESCUELA POLITÉCNICA SUPERIOR UNIVERSIDAD CARLOS III DE MADRID INGENIERÍA TÉCNICA DE TELECOMUNICACIÓN : TELEMÁTICA PROYECTO FIN DE CARRERA DISEÑO Y DESARROLLO DE UN PORTLET PARA LA GESTIÓN DE CURSOS EN LIFERAY INTEGRADO CON EL SISTEMA DE GESTIÓN DE WORKFLOWS JBPM. Autor: Sara Gozalo Macías Tutor: Jesús Arias Fisteus Diciembre de 2010

2

3 No existe cantidad de experimentación que pueda demostrar que tengo razón, pero basta un solo experimento para demostrar que estoy equivocado. Albert Einstein

4

5 Agradecimientos Este momento...el momento en el cual te das cuenta que tras muchos días interminables de biblioteca, cientos de prácticas y mucho esfuerzo, por fin ha llegado el día que todos vemos muy lejos cuando empezamos la carrera, el día en que la terminas. Pero no he llegado sola hasta aquí, porque si no fuera por toda esa gente que me rodea, esto no hubiera sido posible. En primer lugar me gustaría nombrar a mi tutor, D. Jesús Arias Fisteus. Porque gracias a él, me dí cuenta de que todo está relacionado y que siempre existe un camino para encontrar la solución a un problema. Él me acercó al mundo de la programación Web, un mundo que captó todo mi interés y del cual no quiero alejar mi carrera profesional. Gracias por todas esas horas de tutoría, por tu paciencia, tu apoyo y tu ayuda a lo largo de toda mi carrera. Gracias. En segundo lugar quería agradecer el esfuerzo y dedicación de todos los profesores que he tenido durante todos estos años, porque todos han aportado su granito de arena en mi educación. Quería mencionar especialmente a Luis, mi profe de tecno, porque gracias a él aprendí como resolver un circuito con una sonrisa, porque sin él no hubiera sabido que un proyecto de investigación pudiera llegar a ser tan genial, porque...dijo...dijo...dijo...[;)]que este momento llegaría, y ha llegado. Gracias. Pero sin ninguna duda, se lo tengo que agradecer a toda mi familia, por el apoyo continuo que he recibido por su parte durante estos años. Gracias a mis padres, por todo el cariño y ánimo que me han dado. Gracias mamá, papá, por esas sonrisas al llegar a casa todos esos días inacabables de universidad. Mamá gracias por ser tan comprensiva con lo desastre que soy, papá gracias por esos consejos de psicólogo que aunque parezca que no te hago caso, son muy útiles. Y gracias por la excelente formación y educación que nos habéis dado a mi hermana y a mí y por la que siempre estaremos muy agradecidas. Muchas gracias. Miri, gracias por todo, porque sin ti este proyecto no hubiera sido posible. Siempre has sido mi ejemplo a seguir y sabes perfectamente que nunca llegaré a ser MiriV2 porque eres inmejorable. Sé que nunca me perdonarás por todo lo que te rompí cuando era una enana, pero espero que cuentes conmigo para construir el Imperio, ;op. Gracias de verdad. Gracias Sergio por estar ahí durante todos estos años. Gracias por escucharme todas esas tardes, incluso sin entender una palabra de lo que te contaba. Gracias por conseguir sacarme una sonrisa en los peores momentos y por todos los buenos momentos que me has hecho vivir. Eres un sol. En último lugar me gustaría dar las gracias a toda esa gente que me rodea y aunque no lo parezca han sido y son muy importantes: Me gustaría empezar con Bea, mi amiga y compañera de universidad, prácticas, risas, III

6 IV agobios...gracias por aguantar mis visitas continuas al tablón, por no mostrarme tu lado bipolar y hacer que todos esos largos días de biblioteca y prácticas fueran más amenos. Gracias también a mis compañeros y amigos del instituto, en especial a mi grupo de investigación : Noe, Raquel y por supuesto a Silvia, esos dos años sentada a tu lado no los olvidaré nunca. Gracias a toda la gente de música, porque han sido una parte fundamental en mi formación como persona y como músico. Porque aunque no sea el mejor momento para la escuela, vosotros siempre sereis los mejores. Gracias a mis músicos preferidos por todos esos viernes de relax. Y por último quería agradecer todo el ánimo y apoyo que me han dado mis amigos. Gracias por todos esos fines de semana, por vuestras locuras y por todos los buenos momentos juntos. Porque sois muchos y no os puedo mencionar a todos, pero puedo decir que estoy rodeada de dentistas, abogados, biólogos, psicólogos, administradores, ingenieros, arquitectos, etc, sois los mejores. Gracias por todo. GRACIAS A TODOS

7 Resumen Tecnología, Internet, aplicaciones Web...estas palabras son cada día más comunes en nuestro vocabulario. Poco a poco tanto empresas, ministerios y universidades están empezando a usar aplicaciones web para realizar sus trámites, eliminando de esta forma los tediosos papeles. Por ello, los avances en las tecnologías para desarrollar aplicaciones web han sido muy significativos en los últimos años. Las tecnologías también están modificando la forma de comunicación en los grupos de trabajo. Actualmente existen muchos grupos de trabajo que no obtienen los resultados esperados debido a la mala comunicación o la falta de organización. Por ello han aparecido herramientas que organizan y distribuyen las tareas en el grupo de trabajo, mejorando de esta forma la comunicación y organización del grupo. Estas tecnologías son los sistemas de gestión de workflows. Este proyecto se ha basado en estas dos ideas. En un inicio se desarrolló un portlet para gestionar los cursos de formación de la empresa Gridcore AB. Este portlet se implementó para el portal Liferay, mediante las herramientas ICEFaces y JSF que mejoran la interfaz gráfica. Además mediante este portlet es posible gestionar diferentes roles dentro de la empresa como administrador, profesor y alumno. En la segunda parte del proyecto se hizo un estudio acerca de los sistemas de gestión de workflow. A continuación se integró el sistema elegido (JBPM) con el portal Web Liferay, utilizado para el desarrollo del portlet. Gracias a esta integración se pudieron automatizar algunas tareas, facilitando de esta forma la gestión por parte del administrador. Además la integración de ambas tecnologías permitirá gestionar los grupos de trabajo de una forma más simple y esto mejorará su rendimiento. V

8

9 Abstract Technology, Internet, Web applications...all these word are more and more common in our vocabulary. Nowadays, companies, public administration and universities start to use these Web applications on their way to leave the tedious paperworks. Therefore there have been relevant technological advances in web application development on the last few years. Technologies are also changing the way of communication in working groups. Currently there are many working groups that do not get the expected results due to miscommunication or lack of organization. Therefore, tools that organize and distribute tasks in the working group have appeared. These tools have improved communication and group organization. These technologies are called workflow management systems. This project is based on the previous ideas. At first, we developed a portlet for managing trainings at Gridcore AB. This portlet is implemented inside the Liferay portal, using ICEfaces and JSF tools that enhance the user interface. Using this portlet it is also possible to manage different roles within the company; as an administrator, teacher or student. The second part of the project includes a research based on workflow management systems. As a result of the research, JBPM was the system chosen. This system was integrated within the Liferay portal. Thanks to this integration some tasks may be automatized, that improves the management making it easier for the administrator. With this integration the management and performance of working groups have been improved. VII

10

11 Contenidos 1. Introducción Motivación Objetivos Plan de trabajo Estructura de la memoria Estado del Arte J2EE/JEE Aplicaciones empresariales Servidores J2EE Servidores Web Apache Tomcat Glassfish Sistemas de gestión de bases de datos relacionales Postgresql JSF e ICEFaces JavaServer Faces ICEFaces Arquitectura de una aplicación de ICEFaces Portales Web Liferay Desarrollo de portlets con Liferay Workflow Introducción al workflow Bonita Soft workflow Drools Flow JBPM Activiti Evaluación y elección de las tecnologías Elección según los requisitos iniciales Comparación y elección de los sistema de workflow Ejemplo de Activiti Ejemplo jbpm Elección de la tecnología Workflow IX

12 X CONTENIDOS 3.3. Elección de las tecnologías de la segunda parte del proyecto Entornos de desarrollo y Plugins Requisitos Primera parte del proyecto Requisitos funcionales Requisitos no funcionales Segunda parte del proyecto Requisitos funcionales Arquitectura Arquitectura general de la aplicación Arquitectura de software Arquitectura del servidor Primera parte del proyecto Segunda parte del proyecto Diseño Primera parte del proyecto Modelo de datos Diseño del programa a bajo nivel Diseño de la interfaz gráfica Segunda parte del proyecto Modelo de datos Diseño del programa a bajo nivel Diseño de la interfaz gráfica Implementación Desarrollo de la aplicación básica Configuración de la plataforma Creación del portlet y la interfaz gráfica básica Creación de tablas dinámicas con ICEFaces Manejo de eventos y botones Ventanas emergentes Formularios Correo electrónico Estructura página inicial Módulo de archivos Integración de Liferay con JBPM Desarrollo del sistema de workflow Creación del proceso Introducción del workflow en la aplicación

13 CONTENIDOS XI 8. Plan de Pruebas Pruebas de la aplicación base Funcionalidad de Creación de Cursos Sistema de votos y registros Edición de cursos Gestión de pagos Funcionalidad del módulo de archivos Pruebas del sistema de workflow Pruebas de la aplicación con el sistema de workflow Trabajos futuros y conclusiones Conclusiones Trabajos futuros Presupuesto 97 A. Archivos configuración portlet 99 A.1. Archivo portlet.xml A.2. Archivo web.xml B. Clase DataBaseProcess.java 103 C. Archivos configuración Jbpm 107 C.1. Jbpm.cfg.xml C.2. jbpm.hibernate.cfg.xml D. Archivo del proceso de workflow 109 E. Manuals 111 E.1. Logging on E.2. Administrator Manual E.2.1. Creating a General Course E.2.2. Deleting a General Course E.2.3. Creating a Planned Course E.2.4. Deleting a Planned Course E.2.5. Viewing user suggestions E.2.6. Editing a Planned Course E.2.7. Approving a Planned Course E.2.8. Changing a teacher of a course E.2.9. Viewing the number of votes of a Planned Course E Viewing the number of registrations of a Planned Course E Payment confirmation E Deleting registered users of a specific course E.3. Teacher Manual E.3.1. Creating a General Course E.3.2. Editing a Planned Course

14 XII CONTENIDOS E.3.3. Adding files to Planned Courses material E.3.4. Removing files from Planned Courses material E.3.5. Viewing the list of attendees E.3.6. Sending s E.4. User Manual E.4.1. Voting a course E.4.2. Registering in a course E.4.3. Viewing information of a course E.4.4. Downloading courses material E.4.5. Suggesting a course Glosario de Términos 129 Referencias 130

15 Índice de figuras 1.1. Diagrama de Gantt Estructura por niveles de una aplicación empresarial. Fuente: J2EE5 Tutorial Ciclo de vida Java Server Faces (JSF). Fuente: Tutorial de JavaServer Faces Arquitectura ICEFaces.Fuente: ICEFaces Arquitectura de una aplicación con ICEFaces. Fuente: Página Principal de Liferay. Fuente: Liferay Arquitectura de un Portal Web. Fuente: blog/java/que-es-un-portlet.html Muestra de un portal Web, posición de los portlets. Fuente: art= Logo Bonita Soft. Fuente: BonitaSoft Herramientas de Bonita Soft Workflow. Fuente: BonitaSoft Ejemplo representación gráfica de un proceso con Drools Flow. Fuente: Drools Representación gráfica proceso con Java Business Process Management (JBPM). Fuente: Página oficial de JBPM Arquitectura Activiti. Fuente: página oficial Activiti Esquema del proceso del ejemplo de Activiti Representación gráfica del proceso de ejemplo Arquitectura general de la aplicación Arquitectura general de la aplicación en la segunda parte del proyecto Arquitectura MVC: Modelo, Vista, Controlador Arquitectura de la aplicación detallada por módulos Arquitectura de la aplicación detallada por módulo en la segunda parte del proyecto Arquitectura de la aplicación de la primera parte del proyecto Arquitectura de la aplicación de la segunda parte del proyecto Ciclo de vida de un curso Modelo de datos Ejemplo de panel de Pestañas (The ICEfaces Tutorial) Modelo de datos segunda parte del proyecto XIII

16 XIV ÍNDICE DE FIGURAS 7.1. Ejemplo configuración mail en Liferay Ejemplo panelseries en la página principal de la aplicación Persistencia en JBPM (UserGuide JBPM 3) Representación gráfica del proceso de workflow Muestra de los nombres de los cursos generales existentes en la base de datos Página inicial donde se muestran los dos cursos creados Muestra de los cursos existentes en la base de datos Muestra de un proceso de almacenamiento de archivos Muestra de las tablas de JBPM en la base de datos, seguimiento del proceso Proceso evaluación de tareas Presupuesto: costes directos de personal E.1. Form to create an account E.2. Deleting a General course E.3. Form to create a new Planned Course E.4. Viewing user suggestions E.5. Editing a course E.6. Button Approve to approve a Planned Course E.7. How to find out the ID user E.8. Changing the teacher E.9. Number of votes of a course E.10. Number of registered users in a course E.11. Confirming payments E.12. Deleting registered users E.13. Form to create General courses E.14. Adding files E.15. Removing files from material E.16. List of attendees E.17. List of attendees E.18. Voting a course E.19. Registering in a course E.20. Different ways to see the information of a course E.21. Pop-up that shows all the information about a course E.22. How to download a file E.23. How to suggest a course

17 Índice de cuadros 2.1. Tabla de tecnologías capa web Java EE Tabla de comparación de tecnologías de Workflow Presupuesto: costes directos personal por fases Presupuesto: costes directos de los materiales Presupuesto total XV

18

19 Capítulo 1 Introducción 1.1. Motivación Actualmente empresas, administraciones y universidades están tendiendo a digitalizar la información y automatizar sus tareas. Esto es debido a que gracias a las nuevas tecnologías, se puede tener una cantidad muy grande de datos almacenada en un simple ordenador, sin necesidad de tener que reservar un espacio físico para almacenar pilas de papeles como hasta hace unos años. Además este hecho hace que se mejoren las gestiones administrativas y se facilite el acceso a los usuarios a sus propios datos o solicitudes gracias a la gran cantidad de funcionalidades que las nuevas aplicaciones pueden ofrecer. Por todo ello, también se está comenzando a sustituir las páginas web estáticas por portales web dinámicos capaces de ofrecer multitud de funcionalidad tanto a los usuarios como a los desarrolladores. Estos portales web facilitan muchos módulos para tareas de administración que antes debían ser implementados por los desarrolladores. Otro punto a tener en cuenta en las empresas, administraciones y universidades hoy en día, es la importancia de los trabajos en grupo. Algunos ejemplos de esto pueden ser: proyectos desarrollados entre miembros de una misma empresa, proyectos que se desarrollan entre empresas situadas en diferentes países, tareas de administración que necesitan la participación de bastantes personas para su realización, proyectos de investigación en las universidades, etc. Desgraciadamente, en muchos casos los proyectos no cumplen los objetivos planeados o los plazos debido a una mala organización y comunicación entre los diferentes miembros del grupo. Para intentar solucionar estos problemas, en los últimos años han surgido nuevos sistemas de gestión de flujos de trabajo, también denominados sistemas de gestión de workflow. Estos sistemas son capaces de definir un flujo de trabajo determinando diferentes tareas y con posibilidad de definir roles para cada una de ellas. Además, permiten controlar todo el proceso de trabajo. De esta forma, la organización de tareas estaría solucionada. Por otra parte estos sistemas permiten conocer qué tareas están asignadas a cada usuario, con lo cual cada miembro del grupo puede conocer a quién debe acudir en caso de necesitar información o no recibir los datos necesarios para realizar su tarea. Estos sistemas pueden optimizar los proyectos o trabajos en grupos, mejorando de esta forma la rentabilidad en las empresas y administración, y la eficiencia en los ámbitos educativos. Uno de los problemas actuales es la integración de ambas tecnologías, los portales web y los sistemas de gestión de flujos de trabajo. En este momento, existen muy pocos portales 1

20 2 Capítulo 1. Introducción web que integren esta tecnología, aunque muchos de ellos son compatibles con algunos sistemas de gestión de workflow. Por todos estos motivos, la empresa Gridcore AB solicitó la creación de una aplicación web para gestionar uno de los módulos de su página web. Gridcore es una empresa sueca, dedicada a ofrecer soluciones a empresas que necesitan realizar computación de alto rendimiento. Actualmente está modificando los diferentes módulos estáticos de su página Web para convertirlos en módulos dinámicos con más funcionalidad. Esta empresa ofrece cursos sobre cómo gestionar sus sistemas de High Performance Computing (Computación de alto rendimiento) a sus clientes. Actualmente ofrecen estos cursos mediante una página Web estática. Además, el registro y administración de los mismos se realiza de manera manual, es decir, el registro se realiza mediante el envío de una hoja de registro que será posteriormente gestionada por el administrador de la empresa. Esto ocasiona que la gestión sea lenta y costosa para la empresa. Por ello se propuso la realización de este proyecto. La empresa necesita una aplicación que promocione los cursos de una manera más visual a través de su página web en la que los usuarios puedan registrarse de manera automática sin tener que rellenar hojas de registro. Otro problema que existe en la empresa con los cursos es que al tener clientes por todo el mundo, a veces algunos clientes no pueden acudir, por ello también sería recomendable añadir algún mecanismo para poder tener en cuenta las necesidades y opiniones de los clientes respecto a los cursos. Además, en la empresa se realizan muchos proyectos con otras empresas, y siempre ha resultado difícil la organización. Por ello en los últimos meses se han planteado la posibilidad de añadir un sistema de gestión de workflow a su plataforma. Sin embargo aún no han encontrado la forma de integrarlo con su plataforma actual. Estos sistemas también pueden ayudar a automatizar una serie de tareas en las aplicaciones, evitando de esta forma la necesidad de que el administrador tenga que realizar estas tareas. En resumen, este proyecto pretende encontrar e implementar una solución para la gestión de cursos de la empresa. Al mismo tiempo se intentará encontrar una manera de poder integrar los sistemas de workflow en su plataforma para poder mejorar la organización y comunicación en sus proyectos, y automatizar las tareas de las aplicaciones, optimizando el trabajo del administrador Objetivos El propósito principal de este proyecto es desarrollar una aplicación web capaz de proporcionar la funcionalidad necesaria para gestionar la información relativa a los cursos, a los profesores y a los usuarios registrados en los cursos. La aplicación Web permitirá publicar y visualizar información acerca de los cursos: resumen, fechas de inicio y fin, lugar, etc. Se diferenciarán tres tipos diferentes de usuarios: administradores, profesores y alumnos. Los usuarios podrán registrarse en los cursos a través de la plataforma y existirá un mecanismo para poder obtener información acerca de sus preferencias en relación a los cursos. La plataforma utilizada para desarrollar la aplicación deberá ser compatible con los sistemas utilizados actualmente por la empresa. La aplicación tendrá diferentes vistas en relación a los distintos roles existentes. En relación a la interfaz gráfica, se intentará que sea lo más intuitiva, accesible y agradable para los usuarios. Además deberá ser fácil de utilizar a nivel administrativo para que

21 1.3. Plan de trabajo 3 el tiempo de aprendizaje del uso de la aplicación sea el menor posible. En cuanto a la gestión de los cursos de manera automatizada, se planteará la posible integración entre la plataforma utilizada para desarrollar la aplicación y los sistemas de gestión de workflow. Se estudiarán los diferentes sistemas de gestión de flujos de trabajo para poder decidir qué sistema se adapta mejor a la plataforma actual de la empresa. Si se consigue todo lo anterior, se automatizarán ciertas tareas gracias a la integración de los sistemas de gestión de workflow. Por lo tanto algunos de las objetivos que se esperan cumplir son: Existirán tres roles diferenciados en la aplicación: administradores, profesores y alumnos. En la aplicación,se podrán crear, cancelar y editar cursos. Será posible almacenar archivos en cada curso para que los alumnos puedan acceder a ellos. La aplicación contará con un sistema para poder valorar la opinión de los usuarios respecto a los cursos propuestos. Los usuarios también podrán proponer nuevos cursos. Se integrará un sistema de gestión de workflows para automatizar ciertas tareas Plan de trabajo El plan de trabajo es el representado en la figura 1.1 mediante un diagrama de Gantt. A continuación se detalla cada una de éstas fases. Fase 1: Análisis del problema y estudio de la documentación. Esta fase comprende la realización de un exhaustivo estudio sobre los diferentes métodos de creación de portales web. Estos estudios se centrarán en las diferentes tecnologías que utiliza la empresa actualmente para la creación de portlets. Además se planteará la posibilidad de incorporar un sistema de workflow y por lo tanto se estudiarán las tecnologías disponibles en el mercado y las características de cada una de ellas. Fase 2: Recogida de requisitos. Esta fase del proyecto se centra en la recogida e identificación de requisitos funcionales y no funcionales. Para ello se necesitan conocer las características que debe cumplir la aplicación y las tecnologías con las que debe ser compatible. Además se analizarán las necesidades de la empresa y el tiempo del que se dispone para realizar la aplicación. En esta fase se analizarán con especial cuidado los requisitos de software y funcionalidad que serán muy importantes en las siguientes fases del desarrollo del proyecto. Fase 3: Prueba y elección de las diferentes tecnologías. Una vez terminada la recogida de requisitos, se estudiarán las diferentes opciones y se elegirán las tecnologías más adecuadas para el proyecto. Además se realizarán pruebas más detalladas de algunas tecnologías de workflow para poder evaluar cada una de ellas correctamente.

22 4 Capítulo 1. Introducción Fase 4: Diseño de la solución. Esta fase engloba todas las decisiones sobre el diseño y la arquitectura de la aplicación. Es una de las partes más importantes de todo el proyecto, ya que un mal diseño puede ocasionar retrasos, fallos y problemas durante el desarrollo. Se detallará el modelo de datos, el diseño del programa a bajo nivel y el diseño de la interfaz gráfica. Todo el diseño se hará en relación a las tecnologías a utilizar y los diferentes requisitos, tanto funcionales como no funcionales. Fase 5: Implementación de la aplicación base. Tras analizar y diseñar la aplicación, esta fase se basa en la implementación de la misma. Se implementará en un inicio la aplicación básica que cumpla con los requisitos iniciales del cliente. Fase 6: Integración de las diferentes componentes. Una vez finalizada el desarrollo de la aplicación base, se integrarán las diferentes tecnologías y se procederá a la implementación de la segunda parte del proyecto, donde se incluirá el sistema de workflow. Fase 7: Pruebas de la aplicación. Una vez terminada la integración, y dentro de esta misma fase, se realizará la evaluación del funcionamiento del sistema completo. Los resultados de esta evaluación ponen de manifiesto la adecuación del sistema a los requisitos especificados al comienzo del proyecto. Fase 7: Documentación. La etapa final consiste en la redacción del documento que describa en detalle los resultados obtenidos en cada una de las fases del desarrollo del proyecto Estructura de la memoria El resto de la memoria se divide en los siguientes capítulos: Capítulo 2 - Estado del arte: Estudio detallado de las tecnologías utilizadas para la realización del proyecto además de las posibles opciones a estas tecnologías. Capítulo 3 - Evaluación y elección de las tecnologías: Descripción de las valoraciones realizadas para elegir las tecnologías y evaluación más detallada los sistemas de workflow para seleccionar uno de ellos. Capítulo 4 - Requisitos: Descripción de los principales requisitos de la aplicación. Se hará una distinción entre los requisitos funcionales y los no funcionales. Capítulo 5 - Arquitectura: Explicación de la arquitectura de la aplicación. En primer lugar se explicará la arquitectura general, a continuación se entrará algo más en detalle en los módulos de la aplicación. En cuanto a la arquitectura del servidor y del software, se dedicarán secciones específicas para cada uno de ellos. Capítulo 6 - Diseño: Descripción de diseño de la aplicación. Se diferencian las dos partes del proyecto, en cada una de ellas se detalla el modelo de datos, el diseño del programa a bajo nivel y el diseño de la interfaz gráfica.

23 1.4. Estructura de la memoria 5 Capítulo 7 - Implementación: Exposición de los puntos más importantes del desarrollo de la aplicación. Primero se explicará la configuración y desarrollo de la aplicación básica y a continuación se detallará cada una de las funciones. En la segunda parte se describirá la integración de Liferay con jbpm y por último el desarrollo del proceso de workflow de jbpm. Capítulo 8 - Plan de pruebas: Descripción de las pruebas realizadas para comprobar la funcionalidad de la aplicación. Se describen las pruebas de la aplicación base. A continuación, los experimentos realizados para examinar el funcionamiento del sistema de workflow, y por último se explican los procedimientos seguidos para comprobar la funcionalidad de la aplicación global. Capítulo 9 - Trabajos futuros y conclusiones: Exposición de las conclusiones extraídas durante el desarrollo del proyecto fin de carrera, así como indicaciones sobre futuras líneas de trabajo.

24 6 Capítulo 1. Introducción Figura 1.1: Diagrama de Gantt

25 Capítulo 2 Estado del Arte En este capítulo se detallarán las tecnologías utilizadas para la realización del proyecto además de las posibles opciones a estas tecnologías. Antes de comenzar el proyecto se debe investigar acerca de las tecnologías potencialmente utilizables. Si se desea realizar una plataforma web, cumpliendo con las necesidades del cliente, se deben tener en cuenta una serie de tecnologías predeterminadas por el cliente. Este es el caso de la primera parte del proyecto,donde se deben utilizar tecnologías como Liferay, ICEFaces, JSF o Postgresql. Sin embargo, también hay que valorar otras tecnologías que podrían haber sido usadas en lugar de las predeterminadas, ya que ofrecen características similares. En cuanto a la segunda parte del proyecto, en relación a los sistemas de workflow, no existe ningún prerrequisito, y por lo tanto habrá que elegir entre las tecnologías existentes en el mercado, en relación a nuestros objetivos y dificultades que se puedan encontrar. La explicación general de las tecnologías utilizadas para construir el sistema de workflow será comentada en el apartado 2.6. Sin embargo, la evaluación más detallada de algunos de ellos se desarrollará en el siguiente capítulo, terminando con la elección de una de las tecnologías J2EE/JEE La tecnología Java es a la vez un lenguaje de programación y una plataforma. El lenguaje de programación Java es un lenguaje de alto nivel orientado a objetos que tiene una sintaxis y estilo particulares. Una plataforma Java es un entorno en el cual se ejecutan aplicaciones programadas en Java. Hay básicamente tres plataformas del lenguaje de programación Java: Java Platform, Standard Edition (Java SE). Java Platform, Enterprise Edition (Java EE). Java Platform, Micro Edition (Java ME). Todas las plataformas Java están formadas por una Máquina Virtual Java (VM) y una Application Programming Interface (API). La Máquina Virtual Java es un programa, para un equipo específico y una plataforma software, en la cual se ejecutan las aplicaciones Java. Un API es una colección de componentes software que se pueden usar para crear otros componentes de software o aplicaciones. Cada plataforma Java posee una máquina virtual 7

26 8 Capítulo 2. Estado del Arte y un API, y esto permite a las aplicaciones escritas para esa plataforma ser ejecutadas en cualquier sistema compatible, con todas las ventajas que ofrece el lenguaje de programación Java: independencia de plataforma, estabilidad, facilidad de desarrollo y seguridad. Java Platform, Enterprise Edition o Java EE es una plataforma de programación para desarrollar y ejecutar software de aplicaciones en Java con arquitectura de N niveles distribuidos, basándose ampliamente en componentes de software modulares ejecutándose sobre un servidor de aplicaciones. La plataforma Java EE 6 está definida por la especificación Java Specification Requests (JSR) 316 [23]. Similar a otras especificaciones del Java Community Process, Java EE es también considerada informalmente como un estándar debido a que los suministradores deben cumplir ciertos requisitos de conformidad para declarar que sus productos son conformes a Java EE; estandarizado por The Java Community Process (JCP). Java EE incluye varias especificaciones de API, tales como Java Database Connectivity (JDBC), RMI(Remote Method Invocation), correo electrónico, JMS(Java Message Service), Servicios Web, XML(eXtensible Markup Language), etc y define cómo coordinarlos. Java EE también configura algunas especificaciones únicas para Java EE para componentes. Éstas incluyen Enterprise JavaBeans, servlets, portlets (siguiendo la especificación de Portlets Java), JavaServer Pages y varias tecnologías de servicios web. Esto permite al desarrollador crear una Aplicación de Empresa portable entre plataformas y escalable, a la vez que integrable con tecnologías anteriores. Otros beneficios añadidos son, por ejemplo, que el servidor de aplicaciones puede manejar transacciones, la seguridad, escalabilidad, concurrencia y gestión de los componentes desplegados, significando que los desarrolladores pueden concentrarse más en la lógica de negocio de los componentes en lugar de en tareas de mantenimiento de bajo nivel. Se puede encontrar más información acerca de Java Platform Enterprise Edition (J2EE) 1.4 en [11] y acerca de la versión J2EE 5 en [10] Aplicaciones empresariales En este punto se describen las aplicaciones empresariales, cómo están diseñadas y desarrolladas. Como se comentó anteriormente, la plataforma Java EE está diseñada para ayudar a los desarrolladores a crear aplicaciones de red a gran escala, de varios niveles, escalables, confiables y seguras. Una forma corta de llamar a estas aplicaciones es aplicaciones empresariales o entrerprise applications, llamadas así ya que está diseñadas para resolver problemas en ámbitos de empresa o negocio. Las aplicaciones empresariales no son solo útiles para grandes corporaciones, agencias o el gobierno; los beneficios de estas aplicaciones son muy útiles, incluso esenciales para los desarrolladores individuales o pequeñas empresas, debido al incremento de la informatización en las empresas en los últimos años. Las características que hacen que las aplicaciones empresariales sean de gran alcance, como la seguridad y fiabilidad, hacen a menudo a estas aplicaciones un poco más complejas. La plataforma Java EE está diseñada para reducir la complejidad del desarrollo de éstas, proporcionando un modelo de desarrollo, API, y el entorno de ejecución que permite a los desarrolladores concentrarse en la funcionalidad. En una aplicación de varios niveles, la funcionalidad de la aplicación se divide en dife-

27 2.1. J2EE/JEE 9 rentes áreas funcionales, llamados niveles. Normalmente, las aplicaciones de varios niveles tienen un nivel de cliente, un nivel intermedio y un nivel de datos (a menudo llamado nivel de los sistemas de información empresarial). El nivel de cliente consiste en un programa cliente que realiza peticiones a la capa media. Las funciones de negocios del nivel medio tramita las solicitudes del cliente y los datos de proceso de la solicitud, lo guardar en una base de datos en el nivel de datos. El desarrollo de aplicaciones Java EE se concentra en el nivel medio para que la gestión de aplicaciones empresariales sea más fácil, más robusta y más segura. Se pueden observar estos niveles en la figura 2.1 Figura 2.1: Estructura por niveles de una aplicación empresarial. Fuente: J2EE5 Tutorial La capa de cliente: El nivel de cliente se compone de clientes de aplicaciones que acceden a un servidor Java EE y que se encuentran normalmente en un equipo diferente del servidor. Los clientes hacen peticiones al servidor. El servidor procesa las peticiones y devuelve una respuesta al cliente. Hay muchos tipos de aplicaciones que pueden ser clientes de Java EE, y no son siempre aplicaciones Java. Los clientes pueden ser un navegador web, una aplicación independiente, u otros servidores, y se suelen ejecutar, como ya se ha comentado, en un equipo diferente del servidor Java EE. El nivel web: El nivel web se compone de las herramientas que se encargan de la interacción entre los clientes y el nivel de negocios. Sus tareas principales son las siguientes: Generar dinámicamente contenido en varios formatos para el cliente.

28 10 Capítulo 2. Estado del Arte Recoger las peticiones de los usuarios de la interfaz del cliente y devolver los resultados adecuados de los componentes de la capa de negocio. Controlar el flujo de pantallas o páginas en el cliente. Mantener el estado de los datos para la sesión de un usuario. Realizar una lógica básica y mantener algunos datos de forma temporal en los componentes JavaBeans. Las siguientes tecnologías son las usadas en la capa web en las aplicaciones Java EE son las representadas en la figura 2.1. Tecnología Servlets JavaServer Pages JSP JavaServer Faces technology JavaServer Pages Standard Tag Library JavaBeans Components Utilidad Clases del lenguaje de programación Java que procesan peticiones dinámicamente y construyen respuestas, normalmente para páginas HTML. Documentos de texto que son compilados en servlets y define el contenido dinámico que puede ser añadido a páginas estáticas como las páginas HTML. Una arquitectura de componentes de interfaz de usuario para aplicaciones web que permite incluir componentes de interfaz de usuario (por ejemplo, campos y botones) en una página, convertir y validar los datos de los componentes de la interfaz, guardar datos de la interfaz de usuario en el servidor, y mantener el estado de los componentes. Una biblioteca de etiquetas que encapsula la funcionalidad básica común a las páginas JSP Objetos que actúan como almacenes temporales de datos para las páginas de una aplicación. Cuadro 2.1: Tabla de tecnologías capa web Java EE La capa de negocio La capa de negocio está formada por los componentes que proporcionan la lógica de negocio para una aplicación. La lógica empresarial es el código que proporciona la funcionalidad de un dominio de negocio específico, como la industria financiera, o un sitio de comercio electrónico. En una aplicación empresarial adecuadamente diseñada, la funcionalidad básica está en los componentes de nivel de negocio. Las siguientes tecnologías Java EE se utilizan en la capa de negocio en aplicaciones Java EE: Componentes Enterprise JavaBeans. JAX-WS web service endpoints.

29 2.1. J2EE/JEE 11 Java Persistence API entities. El nivel de los Sistemas de Información Empresarial El nivel de los Executive Information System (EIS) se compone de servidores de base de datos, sistemas de planificación de recursos empresariales, y otras fuentes de datos heredados, como los mainframes. Estos recursos normalmente se encuentran en un equipo diferente que el servidor Java EE, y se accede por los componentes de la capa de negocio. Las siguientes tecnologías Java EE se utilizan para acceder al nivel EIS de aplicaciones Java EE: La base de datos API de Conectividad Java (JDBC). El API de Persistencia de Java. La Arquitectura de conectores J2EE. La API de transacciones de Java (JTA) Servidores J2EE Un servidor Java EE es una aplicación de servidor que implementa la API de la plataforma Java EE y proporciona los servicios estándar de Java EE. Los servidores Java EE a veces se llaman servidores de aplicaciones, ya que permiten ofrecer los datos de las aplicaciones a los clientes, como los servidores web sirven las páginas web a los navegadores web. Los servidores Java EE albergan varios tipos de componentes de aplicación que corresponden a los niveles en una aplicación de varios niveles. El servidor Java EE proporciona servicios a estos componentes en la forma de contenedores: Los contenedores Java EE: son la interfaz entre el componente y la funcionalidad de nivel inferior que proporciona la plataforma Java EE para dar soporte a ese componente. La funcionalidad del contenedor se define por la plataforma Java EE, y es diferente para cada tipo de componente. Sin embargo, el servidor Java EE permite a los tipos de componentes diferentes trabajar juntos para proporcionar la funcionalidad de una aplicación empresarial. El contenedor web: es la interfaz entre los componentes de red y el servidor web. Un componente web puede ser un servlet, una página Java Server Pages (JSP), o de una página JavaServer Faces. El contenedor maneja el ciclo de vida del componente, envía las solicitudes de los componentes de aplicación, y proporciona interfaces de datos de contexto, tales como información sobre la solicitud actual. El contenedor de la aplicación cliente: El contenedor de aplicaciones cliente es la interfaz entre los clientes de aplicaciones Java EE, que son aplicaciones Java especiales que utilizan los componentes de Java EE del servidor, y el servidor Java EE. El contenedor de aplicaciones cliente se ejecuta en la máquina cliente, y es la puerta de enlace entre la aplicación cliente y los componentes de Java EE del servidor.

30 12 Capítulo 2. Estado del Arte El contenedor EJB: es la interfaz entre los Enterprise beans, que proporcionan la lógica de negocio en una aplicación Java EE, y el servidor Java EE. El contenedor EJB se ejecuta en el servidor Java EE y administra la ejecución de los Enterprise beans de una aplicación Servidores Web El servidor Web es la base de cualquier aplicación Web. Gracias a él podemos dar disponibilidad a sitios Web cuando son solicitados por usuarios de la red. En este proyecto, en un inicio, es decir durante la fase de desarrollo y pruebas, el propio ordenador de desarrollo servirá como hardware del servidor Web. Una vez superada esta fase, la aplicación básica de gestión de cursos será albergada por un equipo de la propia empresa. Además, se debe tener el software del servidor Web, que no es más que un programa que está diseñado para transferir hipertextos, páginas Web o páginas HTML y que implementa el protocolo Hypertext Transfer Protocol (HTTP). Existen multitud de servidores Web como por ejemplo: Internet Information Server(IIS), Lighttpd, Google Web Server, etc. Pero sin ninguna duda, el más utilizado actualmente es Apache HTTP Server, y muchos de los servidores de aplicaciones actuales se basan en él Apache Tomcat Tomcat (también llamado Jakarta Tomcat o Apache Tomcat) funciona como un contenedor de servlets desarrollado bajo el proyecto Jakarta en la Apache Software Foundation. Tomcat implementa las especificaciones de los servlets y de JavaServer Pages (JSP) de Sun Microsystems. En la página oficial de Apache Tomcat [13], puede encontrarse información más detallada y los archivos de descarga para poder instalarlo. Tomcat es un servidor Web con soporte de servlets y JSPs. Tomcat no es un servidor de aplicaciones, como JBoss o JOnAS. Incluye el compilador Jasper, que compila JSPs convirtiéndolas en servlets. El motor de servlets de Tomcat a menudo se presenta en combinación con el servidor Web Apache. Tomcat puede funcionar como servidor Web por sí mismo. En sus inicios existió la percepción de que el uso de Tomcat de forma autónoma era sólo recomendable para entornos de desarrollo y entornos con requisitos mínimos de velocidad y gestión de transacciones. Hoy en día ya no existe esa percepción y Tomcat es usado como servidor Web autónomo en entornos con alto nivel de tráfico y alta disponibilidad. Dado que Tomcat fue escrito en Java, funciona en cualquier sistema operativo que disponga de la máquina virtual Java. Tomcat es mantenido y desarrollado por miembros de la Apache Software Foundation y voluntarios independientes. Los usuarios disponen de libre acceso a su código fuente y a su forma binaria en los términos establecidos en la Apache Software Licence( [12]). Las primeras distribuciones de Tomcat fueron las versiones 3.0.x. Las versiones más recientes son las 7.x, que implementan las especificaciones de Servlet 2.5 y de JSP 2.1. A partir de la versión 4.0, Jakarta Tomcat utiliza el contenedor de servlets Catalina. Estas son las características de las distintas versiones desarrolladas: 1. Tomcat 3.x (distribución inicial)

31 2.2. Servidores Web Tomcat 4.x 3. Tomcat 5.x 4. Tomcat 6.x 5. Tomcat 7.x Glassfish Implementado a partir de las especificaciones Servlet 2.2 y JSP 1.1 Recarga de servlets Funciones básicas HTTP Implementado a partir de las especificaciones Servlet 2.3 y JSP 1.2 Contenedor de servlets rediseñado como Catalina Motor JSP rediseñado con Jasper Conector Coyote Java Management Extensions (JMX), y administración basada en Struts Implementado a partir de las especificaciones Servlet 2.4 y JSP 2.0 Recolección de basura reducida Capa envolvente nativa para Windows y Unix para la integración de las plataformas Análisis rápido JSP Implementado de Servlet 2.5 y JSP 2.1 Soporte para Unified Expression Language 2.1 Diseñado para funcionar en Java SE 5.0 y posteriores Soporte para Comet a través de la interfaz CometProcessor Implementado de Servlet 3.0 JSP 2.2 y EL 2.2 Mejoras para detectar y prevenir fugas de memoria en las aplicaciones Web Limpieza interna de código Soporte para la inclusión de contenidos externos directamente en una aplicación Web El ejemplo más claro de Servidor de Aplicaciones basado en Apache Tomcat, es Glassfish. GlassFish es un servidor de aplicaciones de software libre desarrollado por Sun Microsystems, Oracle actualmente, que implementa las tecnologías definidas en la plataforma Java EE y permite ejecutar aplicaciones que siguen esta especificación. Es gratuito y de código libre, se distribuye bajo la licencia CDDL y la GNU GPL. GlassFish está basado en el código fuente donado por Sun y Oracle Corporation. Éste último proporcionó el módulo de persistencia TopLink. GlassFish tiene como base al servidor Sun Java System Application

32 14 Capítulo 2. Estado del Arte Server de Oracle Corporation, un derivado de Apache Tomcat, y que usa un componente adicional llamado Grizzly basado en Java NIO para escalabilidad y velocidad. Además proporciona total compatibilidad con Liferay, puede administrar las aplicaciones Java Platform Enterprise Edition (JEE) (generalmente servlet/jsp y EJB); y es recomendable utilizar Glassfish para las aplicaciones empresariales de J2EE/JEE. Sin embargo, Glassfish no da soporte para el sistema de workflow JBPM, aspecto a tener en cuenta a la hora de elegir un servidor para desarrollar la aplicación. En [4], la página oficial de la comunidad Glassfish, se puede encontrar más información acerca de este servidor de aplicaciones Sistemas de gestión de bases de datos relacionales Los sistemas de gestión de bases de datos son un tipo de software muy específico, dedicado a servir de interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan. Existen distintos objetivos que deben cumplir los SGBD: Abstracción de la información. Los SGBD ahorran a los usuarios detalles acerca del almacenamiento físico de los datos. Da lo mismo si una base de datos ocupa uno o cientos de archivos, este hecho se hace transparente al usuario. Así, se definen varios niveles de abstracción. Independencia. La independencia de los datos consiste en la capacidad de modificar el esquema (físico o lógico) de una base de datos sin tener que realizar cambios en las aplicaciones que se sirven de ella. Consistencia. En aquellos casos en los que no se ha logrado eliminar la redundancia, será necesario vigilar que aquella información que aparece repetida se actualice de forma coherente, es decir, que todos los datos repetidos se actualicen de forma simultánea. Por otra parte, la base de datos representa una realidad determinada que tiene determinadas condiciones, por ejemplo que los menores de edad no pueden tener licencia de conducir. El sistema no debería aceptar datos de un conductor menor de edad. En los SGBD existen herramientas que facilitan la programación de este tipo de condiciones. Seguridad. La información almacenada en una base de datos puede llegar a tener un gran valor. Los SGBD deben garantizar que esta información se encuentra segura de permisos a usuarios y grupos de usuarios, que permiten otorgar diversas categorías de permisos. Manejo de transacciones. Una transacción es un programa que se ejecuta como una sola operación. Esto quiere decir que luego de una ejecución en la que se produce un fallo, el estado es el mismo que se obtendría si el programa no se hubiera ejecutado. Los SGBD proveen mecanismos para programar las modificaciones de los datos de una forma mucho más simple que si no se dispusiera de ellos. Tiempo de respuesta. Lógicamente, es deseable minimizar el tiempo que el SGBD tarda en devolver la información solicitada y en almacenar los cambios realizados.