SecureGest. Un Sistema Web para la gestión de la seguridad privada. Documento de Diseño e Implementación del Sistema. Versión 1.

Transcripción

1 Un Sistema Web para la gestión de la seguridad privada Documento de Diseño e Implementación del Sistema Versión 1.1 Fecha 06/07/2009 Preparado para: Departamento de Lenguajes y Sistemas Informáticos Preparado por: Antonio Romero Solís Dirigido por: Sergio Pozo Hidalgo Departamento: Departamento Lenguajes y Sistemas Informáticos Antonio Romero Solís Página 1

2 1 LISTA DE CAMBIOS Número Fecha Descripción Autores Antonio Romero Solís Página 2

3 2 ÍNDICE 1. Lista de cambios 2 2. Índice Introducción Objetivos 6 5. Alternativas de diseño Lenguajes de implementación Web Cold Fusion Java Servlet PHP Hypertext Pre-processor (PHP) Active Server Pages (ASP) JavaServer Pages (JSP) ASP.NET exetensible Server Pages (XSP) JavaServer Faces (JSF) Ruby on Rails Perl Valoración de alternativas al lenguaje de implementación Sistemas Gestores de Bases de Datos Oracle MySQL Postgre SQL SQL Server Valoración de alternativas al Sistema Gestor de Bases de Datos Patrones de Diseño Patrón Arquitectónico Orientado a Capas (Layers) Niveles de Arquitectura Capa de Presentación Capa de Aplicación Capa de Datos Patrón Singleton Patrón Dao Patrón Front Controller Introducción a los Servlet y JSP Introducción al protocolo HTTP Las JavaServer Pages (JSP s) La API Servlet Ciclo de vida y características especiales de los Servlet Número de Máquinas Virtuales Java Persistencia de instancias Recarga de Servlet Creación, vida y destrucción Antonio Romero Solís Página 3

4 7.4.5 Servlet monotarea Procesamiento en segundo plano Caché en el cliente Caché en el servidor Reparto de trabajo Proxy Implementación: Entorno y Herramientas de Desarrollo Implementación del código JAVA Implementación de las JavaServer Pages (JSP s) Servidor Web y/o de Aplicaciones Base de Datos Tecnologías RIA utilizadas en el proyecto JavaScript Editor de Textos (TinyMCE) Plugins de Eclipse utilizados Diseño Navegacional Navegación Administrador Navegación principal del Administrador Navegación del Subsistema Empleados Navegación del Subsistema Clientes Navegación del Subsistema Empresas Navegación del Subsistema Cuadrantes Navegación del Subsistema Servicios Navegación del Subsistema Delegaciones Navegación Empleado Detalles de implementación Base de Datos del Sistema Capa de Presentación Autenticación de Usuario Fichero descriptor de despliegue Estructura de interfaces Capa de Aplicación Capa de Datos Implementación de las clases de la capa de datos Bibliografía Antonio Romero Solís Página 4

5 3 INTRODUCCIÓN El Proyecto consiste en la implementación de una aplicación Web para la gestión y mantenimiento de una empresa de seguridad privada, así como para ofrecer una plataforma de comunicación entre administradores y empleados, y entre los propios empleados. Entre otras cosas la aplicación permite generar automáticamente los cuadrantes de empleados para los distintos servicios, liberando al administrador de una gran carga de trabajo, pudiendo contar así con más tiempo para dedicarlo a otras actividades de sus competencias, también se encarga de gestionar todo lo referente al modelo de negocio de las empresas de seguridad. Otra de los objetivos que pretende conseguir la aplicación es el aumento de bienestar y satisfacción de los empleados, al buscar una solución en la asignación de empleados en los cuadrantes de manera que satisfaga en la medida de lo posible a todos, además de disponer de una herramienta versátil de comunicación y de acceso a información. Para que la mejora con respecto a los empleados se reflejen en la realidad es necesario que fuera de fácil acceso para los mismos y que la aplicación fuera independiente de la plataforma de los empleados, por lo que la decisión de hacer una aplicación web se perfilaba como la mejor. El sistema se ha diseñado utilizando una arquitectura en tres capas (capa de presentación, capa de lógica de negocio y capa de datos), asegurando así la independencia entre presentación, la base de datos e implementación de operaciones y facilitando el posterior mantenimiento de las capas. Para la construcción de una aplicación con mejores prestaciones y solucionar problemas de rendimiento se han aplicado patrones para el diseño, como el patrón Front Controller que controla que sólo los usuarios de la aplicación puedan utilizar las herramientas de la aplicación mediante la implementación del módulo de autenticación en el mismo. La aplicación web se ha desarrollado utilizando la tecnología Java (JSP y Servlet) y el gestor de base de datos MySQL, ya que ambas permiten el dinamismo y la portabilidad requeridos por este tipo de aplicaciones. La presentación y estilo de la aplicación se ha realizado con CSS2. Estas últimas tecnologías aseguran la independencia del navegador. Antonio Romero Solís Página 5

6 4 OBJETIVOS La aplicación en cuestiones relativas al diseño, plantea varios objetivos de diferente índole, siendo algunos de carácter técnico y otros estratégicos. En todas las herramientas usadas en el proceso de diseño y desarrollo hemos buscado que sean de software libre. En los sucesivos apartados se plantearán las diferentes variantes y sus valoraciones, pero se puede adelantar que tanto el desarrollo con herramientas como Eclipse y MySQL Administrator, como la plataforma destinada a ejecutar la aplicación Web que es Tomcat y el sistema de gestión de base de datos MySQL cumplen con esta premisa. Así mismo, el servidor Web y de base de datos, puede ser instalado sobre varios tipos de sistemas operativos, como por ejemplo GNU Linux, que cumple sobradamente con el requisito comentado. Otro fin buscado con esta aplicación era la facilidad de uso de la misma, precisando para ello de un entorno intuitivo que facilitara el uso a personas con distinto nivel técnico en lo relativo al uso de ordenadores y aplicaciones informáticas.. Por tanto, en el diseño se ha tenido especial cuidado que este requisito fuera cubierto. Por ello, el diseño se ha realizado enfocado a que cualquier tipo de usuario pueda usar sin problemas, derivado de su nivel de conocimiento, esta aplicación. La gestión de toda la información referente al modelo de negocio de las empresas de seguridad es un objetivo primario facilitando en la medida de lo posible el mantenimiento y actualización del conjunto de clientes, servicios, empleados, cuadrantes... En definitiva, debía suponer una tarea sencilla para el administrador realizar cualquier operación sobre estos conjuntos. A lo largo del documento, se podrá apreciar cómo estos objetivos principales han sido la clave en la toma de decisiones de las diferentes fases por las que ha atravesado el Proyecto, así como otros muchos aspectos que han ido surgiendo en cada sección y que han motivado, tras un estudio de los mismos, las diferentes tomas de decisiones. 5 ALTERNATIVAS DE DISEÑO El proyecto es, básicamente, una aplicación Web. Alternativas para implementar este tipo de aplicaciones existen muchísimas, algunas de las cuales son de nueva creación, y otras son una evolución de otras alternativas que existieron en un tiempo pasado y dieron paso a otras que suponían una mejora en ese tipo de implementaciones. Seguidamente hacemos un repaso histórico en orden decreciente de antigüedad de implementaciones que hoy en día se utilizan con más o menos frecuencia, pero de las cuales podíamos haber elegido cualquiera para implementar el proyecto que nos incumbe. A su vez se hará una valoración de estas alternativas para llegar a la conclusión de Antonio Romero Solís Página 6

7 cual es la que más se adapta a nuestras necesidades como implementadores de este proyecto. 5.1 Lenguajes de implementación Web Cold Fusion Cold Fusion fue desarrollado inicialmente por J. J. Allaire, es una plataforma de desarrollo completa, en la que su primera versión apareció en julio de En 2001, estando en el mercado la versión 5, Allaire fue adquirido por Macromedia (actualmente Adobe) la cual pretendió seguir con la base de Cold Fusion, pero adaptándolo a los lenguajes estaban haciendo furor o en un futuro cercano iban a hacerlo entre el mundo de los desarrolladores. Consta de un lenguaje de programación, un servidor de aplicaciones, un entorno de desarrollo y un framework para desarrollar servicios empresariales. Funciona bajo Linux, Solaris y Windows. En esta alternativa, el servidor de aplicaciones de Cold Fusion procesa las peticiones HTTP. Si se pide una página cfm (Cold Fusion), el servidor de aplicaciones ejecuta el o los scripts que contenga esa página. Estos scripts son añadidos a las páginas HTML, y están basados en tags, de modo que es una de las alternativas más fáciles de programar. Entre los beneficios del uso de Cold Fusion encontramos que es el sistema de desarrollo en el que menos tiempo se tarda en completar una aplicación (ya que está todo integrado y relacionado dentro del mismo paquete), alta escalabilidad, se necesita menos programación y la depuración es más fácil y rápida (una vez más por la relación entre todos los componentes del paquete). Además, posee una API bastante rica (posee estructuras de datos avanzadas, control de excepciones, acceso de a bases de datos...). Una de las funciones más poderosas de Cold Fusion, es la posibilidad que ofrece para leer desde y escribir en discos duros del servidor. No es un lenguaje de bases de datos, pero interactúa de manera simple con bases de datos (Sybase, Oracle, MySQL, SQL Server, o Access). Usando SQL estándar, las páginas y aplicaciones Web pueden fácilmente recuperar, guardar, formatear y presentar información dinámicamente. El mayor inconveniente que se le puede achacar es que es una solución propietaria y por ello el coste de implementación y de implantación de la aplicación aumenta de forma considerable Java Servlets Los Servlets son objetos que corren dentro del contexto de un contenedor de Servlets y extienden su funcionalidad. También podrían correr dentro de un servidor de Antonio Romero Solís Página 7

8 aplicaciones que además de contenedor para Servlet tendrá contenedor para objetos más avanzados como son los Enterprise JavaBeans. Más concretamente, un Servlet es una extensión genérica del servidor desarrollada por Sun a partir del lenguaje Java. Es, en definitiva, una clase Java que se puede cargar dinámicamente para aumentar la funcionalidad de del servidor. La palabra Servlet deriva de otra anterior, applet, que se refería a pequeños programas escritos en Java que se ejecutan en el contexto de un navegador Web. Por contraposición, un Servlet es un programa que se ejecuta en un servidor. El uso más común de los Servlets es generar páginas Web de forma dinámica a partir de los parámetros de la petición que envíe el navegador Web siendo procesados por esta clase Java. Al ser una clase Java, tiene todas las ventajas e inconvenientes que posee este lenguaje de programación: es seguro, multiplataforma (tanto a la hora del desarrollo como de la ejecución), tiene un soporte muy amplio por parte de desarrolladores de aplicaciones y servidores de aplicaciones (muchos de ellos gratuitos), una API muy extensa (toda la de Java), una API específica para acceder a bases de datos (JDBC y ODBC), etcétera. Los Servlets funcionan en el dominio del servidor, y al contrario que los Applets, no necesitan que los navegadores cliente tengan soporte Java. Además, al contrario que con los CGI y sus derivados, los Servlets pueden ser manejados por hilo separados dentro del mismo proceso, o dentro de procesos múltiples (que pueden estar en distintos servidores y máquinas). Es decir, cuando se llama a un Servlet, éste se carga en memoria y se queda ahí hasta que el servidor de aplicaciones se cierra, de modo que para cada una de las llamadas a él, se crea un hilo independiente y por ello los Servlets son eficientes y escalables (figura 5.3). Además poseen la cualidad de poner mantener una comunicación bidireccional con el servidor, de modo que puedan interactuar con él y realizar tareas que son posibles con los CGI. Antonio Romero Solís Página 8

9 5.1.3 PHP Hypertext Pre-processor (PHP) Es un lenguaje de programación usado frecuentemente para la creación de contenido para sitios Web con los cuales se puede programar las páginas html y los códigos de fuente. Se trata de un lenguaje interpretado usado para la creación deaplicaciones para servidores, o creación de contenido dinámico para sitios Web. Últimamente también para la creación de otro tipo de programas incluyendo aplicaciones con interfaz gráfica usando las librerías GTK+. PHP es Open Source y, al ser multiplataforma, funciona en una gran variedad de servidores Web, incluyendo Apache y Microsoft Internet Information Server. Respecto a su forma de funcionar, decir que es muy similar a cualquier otro lenguaje de scripting, mezclando HTML y código PHP. Es una mezcla de influencias (incluyendo Perl, C, Java e incluso ASP). PHP es muy extensible, y debido a que es Open Source, existen diversidad de extensiones para realizar todo tipo de tareas (entre las que se encuentran la conexión a bases de datos, gestión de correo electrónico, parsing XML, LDAP...) Es precisamente esa gran variedad de APIs la desventaja de este lenguaje, ya que llega a producirse una gran inconsistencia entre módulos y los desarrolladores tienen que estar muy pendientes de los cambios que se produzcan en cada módulo externo al lenguaje que haya usado. Precisamente, unos de los problemas más grandes que se deriva de esta falta de estandarización en los módulos, es la falta de una API estándar para acceder a bases de datos, de modo que si por ejemplo, queremos conectarnos con una base de datos en PostgreSQL, tendremos que utilizar código específico de la API de Postgres, lo que deriva irremediablemente en una pérdida de portabilidad muy importante. Por otra parte, no existen demasiadas herramientas de apoyo para los desarrolladores, tanto para programar como para depurar. Los principales usos del PHP son los siguientes: * Programación de páginas Web dinámicas, habitualmente en combinación con el motor de base datos MySQL, aunque cuenta con soporte nativo para otros motores, incluyendo el estándar ODBC, lo que amplía en gran medida sus posibilidades de conexión. * Programación en consola, al estilo de Perl o Shell scripting. * Creación de aplicaciones gráficas independientes del navegador, por medio de la combinación de PHP y GTK (GIMP Tool Kit), lo que permite desarrollar aplicaciones de escritorio en los sistemas operativos en los que está soportado. Antonio Romero Solís Página 9

10 5.1.4 Active Server Pages (ASP) Es una tecnología del lado servidor de Microsoft para páginas Web generadas dinámicamente, que ha sido comercializada como un anexo a Internet Information Server (IIS). Intenta ser solución para un modelo de programación rápida ya que programar en ASP es como programar en VisualBasic. Posee un gran soporte por parte de la industria (empezando porque el ASP de distribuye por defecto con Internet Information Server, el servidor de aplicaciones que se entrega por defecto con las versiones servidor de WindowsNT, Windows2000 y WindowsXP). Este es uno de los motivos por los que los desarrolladores ASP son relativamente fáciles de encontrar. El lenguaje de scripting es concretamente, VBScript o Jscript, de modo que el esfuerzo de aprendizaje para los desarrolladores de Visual Basic es mínimo. VBScript soporta variables no declaradas, proporciona acceso fácil a toda la API de Windows a través del soporte nativo de COM (Component Object Model) -lo que puede convertirse en un arma de doble filo al crecer en complejidad el código y a la vez el tiempo de desarrollo, ya que los componentes COM son muy complejos de realizar-, y finalmente, acceso fácil y unificado a bases de datos a través de ADO (Active Data Objects). Posee además control de errores a través de las palabras claves try/match típicas y tiene un amplio abanico de aplicaciones de apoyo a desarrolladores (entornos de desarrollo, depuradores...), así como se pueden incluir dentro de una aplicación objetos ya desarrollados Activex. Sin embargo, esta opción nos ata a una misma plataforma tanto para el desarrollo como para la puesta en servicio de la aplicación: Microsoft Windows. Además por supuesto, no existe forma alguna de hacer funcionar a una aplicación ASP en un servidor de aplicaciones que no sea Microsoft IIS o PWS bajo una plataforma Windows (a menos que no utilicemos componentes COM, lo que haría algunas tareas imposibles de realizar), con el incremento de coste que conlleva. Otra característica de las páginas ASP es que son recompiladas cada vez que un cliente hace una petición (aunque sea de la misma página e incluso con los mismos parámetros). ASP está optimizado para introducir pequeños fragmentos de código en el fichero HTML, de modo que se derive todo el trabajo a los componentes COM. Antonio Romero Solís Página 10

11 5.1.5 JavaServer Pages (JSP) Las páginas JSP son la alternativa de Sun a las ASP de Microsoft. La sintaxis de JSP es similar a la de ASP, con la diferencia de que JSP utiliza scriplets (trozos de código embebido dentro de los ficheros HTML) en lenguaje Java (con todas las propiedades de este lenguaje y acceso completo a su API). Sin embargo, JSP no se puede considerar un script al 100%, ya que, antes de ejecutarse, el servidor Web compila el script y genera un Servlet. La ventaja de ello es algo más de rapidez y disponer del API de Java en su totalidad. Al contrario que ASP, JSP es un estándar abierto implementado por muchísimas empresas y para muchas plataformas. De hecho, Sun donó el código fuente de un servidor de aplicaciones de referencia al proyecto Apache, el servidor Web más frecuente entre los sitios de Internet. Además, otras muchas empresas (como son Borland e IBM) han realizado servidores de aplicaciones, entornos de desarrollo y diversas herramientas de apoyo a los desarrolladores de todos los tipos y gamas posibles, y que son en su mayor parte, multiplataforma, ya que suelen estar programadas en Java. El sistema de funcionamiento de los JSP es una mezcla de las páginas ASP y los Servlets. Al igual que las páginas ASP, las JSP son una mezcla de código y HTML, pero en el caso de JSP, las páginas se compilan a un Servlet la primera vez que se accede a ellas, siendo todo el proceso interno al servidor. Este paso consigue eliminar casi del todo el problema de las páginas ASP, que tienen que interpretarse cada vez que se llaman (el casi es porque no debemos olvidar que las clases Java son interpretadas por una máquina virtual). Como no podía ser de otro modo, las páginas JSP proporcionan acceso fácil a componentes (JavaBeans) programados en Java y acceso cómodo y fácil a bases de Antonio Romero Solís Página 11

12 datos (JDBC). Además, JSP soporta custom tags, al estilo de Cold Fusion, con lo que la programación de este tipo de páginas puede reducirse al uso de tags, como si de un lenguaje de marcado al estilo de XML se tratase ASP.NET ASP.NET es un conjunto de tecnologías de desarrollo de aplicaciones Web comercializado por Microsoft. Es usado por programadores para construir sitios Web domésticos, aplicaciones Web y servicios XML. Forma parte de la plataforma.net de Microsoft y es la tecnología sucesora de la tecnología Active Server Pages (ASP). Microsoft ha desarrollado una nueva tecnología denominada ASP.NET, como parte de la estrategia.net para el desarrollo Web, con el objetivo de resolver las limitaciones de ASP y posibilitar la creación de software como servicio. ASP.NET es la plataforma unificada de desarrollo Web que proporciona a los desarrolladores los servicios necesarios para crear aplicaciones Web empresariales. Cualquier persona que esta familiarizada con el desarrollo de aplicaciones Web sabrá que el desarrollo Web no es una tarea simple. Ya que mientras que un modelo de programación para aplicaciones de uso común está muy bien establecido y soportado por un gran número de lenguajes, herramientas de desarrollo, la programación Web es una mezcla de varios lenguajes de etiquetas, un gran uso de scripting y plataformas de servidor. Desafortunadamente para el programador de nivel intermedio, el conocimiento y habilidades que se necesitan para desarrollar aplicaciones WEB tienen muy poco en común con las que son necesarias en el desarrollo tradicional de aplicaciones. Antonio Romero Solís Página 12

13 Pero como casi siempre ocurre, todo lo que reluce no es oro, ni todas las actualizaciones de un lenguaje significan una mejora en todos los aspectos. En el modelo de desarrollo Web basado en páginas activas, la programación ASP.NET actual tiene diversas limitaciones: * Para que todo ocurra en una página Web, es habitual escribir una gran cantidad de código para resolver necesidades sencillas. Incorpora un modelo declarativo a la programación Web: los controles de servidor funcionan en una página Web simplemente declarándolos. Cuando se carga la página, se instancian los controles listados en la página y es responsabilidad del control emitir código HTML que el navegador pueda entender. * Es un tanto desorganizado. En una página podemos incluir casi todo: HTML plano, código de scripting, objetos COM y texto. No hay una distinción formal entre el contenido de una página y su comportamiento: simplemente, insertamos código en la página, y a ver qué pasa. ASP.NET impone un cierto orden sobre el modelo de programación estándar ASP. * La tercera limitación en el desarrollo con este tipo de lenguaje es que con el tradicional (ASP) utilizamos lenguajes de scripting no tipificados como VBScript o JScript. Podemos instalar otros motores de scripting que impongan verificación de tipos; sin embargo, no son universalmente conocidos o utilizados como los anteriores. ASP.NET claramente separa la porción basada en script de una página Web de su contenido extensible Server Pages (XSP) XSP es la última evolución de las páginas servidor. Su significado es Páginas de Servidor Extensibles (extensible Server Pages) y es una de las tecnologías que forman parte de Cocoon, que es una de las siete partes de las que consta el proyecto XML de Apache. El paradigma de Cocoon se basa en el hecho de que el contenido, el estilo y la lógica del documento se crean habitualmente por personas diferentes o grupos de trabajo distintos. Cocoon aboga por una separación completa de las tres capas, separándolas en ficheros XML distintos, de modo que se usen transformaciones XSL para unirlas. Esta tecnología tiene mucho en común con las páginas JSP de Sun, pero también posee algunas diferencias importantes que se describen a continuación. Tal como en Java se pretende que exista una clara separación del contenido y la lógica de la negocio, en XSP se pretende lo mismo pero con aplicaciones basadas en XML. Aunque muchos de los paquetes o frameworks para trabajo en XML permiten esta separación en capas junto con el código compilado, los cambios de formato en Antonio Romero Solís Página 13

14 documentos XML todavía requieren cambios en el código Java y la consecuente recompilación. Cocoon se basa en principalmente en transformaciones XSLT (extensible Stylesheet Language Transformation, Transformación extensible del lenguaje de hojas de estilo), que permite una completa separación entre contenido y estilo. Cocoon va todavía más lejos que XSLT, y pretende conseguir un camino para separar el contenido y el estilo de la lógica de programación que rige el comportamiento en el servidor. Por ello, XSP es una pieza más en el puzzle XML. XSP funciona traduciendo código de entrada (un árbol DOM) en código de salida (posiblemente otro árbol DOM), de modo que luego transformará en código fuente la primera vez que se llame a la página, se compilará y se ejecutará. Para las llamadas siguientes, se ejecutará el código precompilado. Al igual que ASP.NET, XSP es una tecnología en desarrollo, pero en una fase aún más precaria que ASP.NET. Igualmente, parece mucho más compleja (ya que utiliza tecnologías de más bajo nivel), a la vez que más avanzada por el mismo motivo JavaServer Faces (JSF) La tecnología JavaServer Faces es un marco de trabajo de interfaces de usuario del lado de servidor para aplicaciones Web basadas en tecnología Java. Los principales componentes de la tecnología JavaServer Faces son: * Un API y una implementación de referencia para: representar componentes UI y manejar su estado; manejo de eventos, validación del lado del servidor y conversión de datos; definir la navegación entre páginas; soportar internacionalización y accesibilidad; y proporcionar extensibilidad para todas estas características. * Una librería de etiquetas JavaServer Pages (JSP) personalizadas para dibujar componentes UI dentro de una página JSP. Antonio Romero Solís Página 14

15 En su mayoría, las aplicaciones JavaServer Faces son como cualquier otra aplicación Web Java. Se ejecutan en un contenedor Servlet Java, y típicamente contienen: Componentes JavaBeans (llamados objetos del modelo en tecnología JavaServer Faces) conteniendo datos y funcionalidades específicas de la aplicación; Oyentes de Eventos; Páginas, cómo páginas JSP; Y clases de utilidad del lado del servidor, como beans para acceder a las bases de datos. Una de las grandes ventajas de la tecnología JavaServer Faces es que ofrece una clara separación entre el comportamiento y la presentación. La separación de la lógica de la presentación también le permite a cada miembro del equipo de desarrollo de una aplicación Web enfocarse en su parte del proceso de desarrollo, y proporciona un sencillo modelo de programación para enlazar todas las piezas. Otro objetivo importante de la tecnología JavaServer Faces es mejorar los conceptos familiares de componente-ui y capa- Web sin limitarnos a una tecnología de script particular o un lenguaje de marcas. Pero lo más importante, la tecnología JavaServer Faces proporciona una rica arquitectura para manejar el estado de los componentes, procesar los datos, validar la entrada del usuario, y manejar eventos. Antonio Romero Solís Página 15

16 5.1.9 Ruby on Rails Ruby on Rails, también conocido como RoR o Rails es un framework de aplicaciones web de código abierto escrito en el lenguaje de programación Ruby, siguiendo el paradigma de la arquitectura Modelo Vista Controlador (MVC). Trata de combinar la simplicidad con la posibilidad de desarrollar aplicaciones del mundo real escribiendo menos código que con otros frameworks y con un mínimo de configuración. El lenguaje de programación Ruby permite la metaprogramación, de la cual Rails hace uso, lo que resulta en una sintaxis que muchos de sus usuarios encuentran muy legible. Rails se distribuye a través de RubyGems, que es el formato oficial de paquete y canal de distribución de librerías y aplicaciones Ruby. Los principios fundamentales de Ruby on Rails incluyen No te repitas (del inglés Don't repeat yourself, DRY) y Convención sobre configuración. No te repitas significa que las definiciones deberían hacerse una sola vez. Dado que Ruby on Rails es un framework de pila completa, los componentes están integrados de manera que no hace falta establecer puentes entre ellos. Por ejemplo, en ActiveRecord, las definiciones de las clases no necesitan especificar los nombres de las columnas; Ruby puede averiguarlos a partir de la propia base de datos, de forma que definirlos tanto en el código como en el programa sería redundante. Convención sobre configuración significa que el programador sólo necesita definir aquella configuración que no es convencional. Por ejemplo, si hay una clase Historia en el modelo, la tabla correspondiente de la base de datos es historias, pero si la tabla no sigue la convención (por ejemplo blogposts) debe ser especificada manualmente (set_table_name "blogposts"). Así, cuando se diseña una aplicación partiendo de cero sin una base de datos preexistente, el seguir las convenciones de Rails significa usar menos código (aunque el comportamiento puede ser configurado si el sistema debe ser compatible con un sistema heredado anterior) Arquitectura MVC de Rails En las aplicaciones web orientadas a objetos sobre bases de datos, el Modelo consiste en las clases que representan a las tablas de la base de datos. En Ruby on Rails, las clases del Modelo son gestionadas por ActiveRecord. Por lo general, lo único que tiene que hacer el programador es heredar de la clase ActiveRecord::Base, y el programa averiguará automáticamente qué tabla usar y qué columnas tiene. Las definiciones de las clases también detallan las relaciones entre clases con setencias de mapeo objeto relacional. Por ejemplo, si la clase Imagen tiene una definición has_many:comentarios, y existe una instancia de Imagen llamada a, entonces a.comentarios devolverá un array con todos los objetos Comentario cuya columna imagen_id (en la tabla comentarios) sea igual a a.id. Las rutinas de validación de datos (p.e. validates_uniqueness_of:checksum) y las rutinas relacionadas con la actualización (p.e. after_destroy:borrar_archivo, before_update:actualizar_detalles) también se especifican e implementan en la clase del modelo. En MVC, Vista es la lógica de visualización, o cómo se muestran los datos de las clases del Antonio Romero Solís Página 16

17 Controlador. Con frecuencia en las aplicaciones web la vista consiste en una cantidad mínima de código incluido en HTML. Existen en la actualidad muchas maneras de gestionar las vistas. El método que se emplea en Rails por defecto es usar Ruby Embebido (archivos.rhtml, desde la versión 2.x en adelante de RoR archivos.html.erb), que son básicamente fragmentos de código HTML con algo de código en Ruby, siguiendo una sintaxis similar a JSP. También pueden construirse vistas en HTML y XML con Builder o usando el sistema de plantillas Liquid. Es necesario escribir un pequeño fragmento de código en HTML para cada método del controlador que necesita mostrar información al usuario. El "maquetado" o distribución de los elementos de la página se describe separadamente de la acción del controlador y los fragmentos pueden invocarse unos a otros. En MVC, las clases del Controlador responden a la interacción del usuario e invocan a la lógica de la aplicación, que a su vez manipula los datos de las clases del Modelo y muestra los resultados usando las Vistas. En las aplicaciones web basadas en MVC, los métodos del controlador son invocados por el usuario usando el navegador web. La implementación del Controlador es manejada por el ActionPack de Rails, que contiene la clase ApplicationController. Una aplicación Rails simplemente hereda de esta clase y define las acciones necesarias como métodos, que pueden ser invocados desde la web, por lo general en la forma que invoca a EjemploController#metodo, y presenta los datos usando el archivo de plantilla /app/views/ejemplo/metodo.html.erb, a no ser que el método redirija a algún otro lugar. Rails también proporciona andamiaje, que puede construir rápidamente la mayor parte de la lógica y vistas necesarias para realizar las operaciones más frecuentes. Ejemplo de web hecha en Ruby on Rails: Antonio Romero Solís Página 17

18 Perl El lenguaje Perl toma su nombre de Practical Extraction and Report Language y fue ideado por Larry Wall. La primera versión sale en el año de Originalmente Larry Wall lo describe como un excelente lenguaje optimizado para leer archivos de texto, extraer información de esos archivos y crear reportes basados en esa información, combinando lo mejor de C, sed, awk y sh. Para los que conocen alguno de los lenguajes y herramientas antes mencionados, se podrán dar cuenta que la sintáxis del lenguaje es muy similar y no tendrán mucho problema en adoptarlo. Perl se considera un lenguaje interpretado, es decir, no es necesaria una previa compilación para poder ejecutarse, lo único que se necesita es darle al interprete, perl, el código que queremos que ejecute. Desde sus inicios Perl ha avanzado mucho y ahora se encuentra en la versión 5 con la versión 6 en pleno desarrollo. Cabe mencionar que Perl hoy en día es usado para una gran variedad de cosas, desde avanzados programas de seguridad hasta sencillos CGIs para administrar formularios. Uno de los fuertes de Perl es la existencia de CPAN, un directorio de módulos que podemos integrar a nuestros scripts para facilitarnos la vida. La estructura completa de Perl deriva ampliamente del lenguaje C. Perl es un lenguaje imperativo, con variables, expresiones, asignaciones, bloques de código delimitados por llaves, estructuras de control y subrutinas. Perl también toma características de la programación shell. Todas las variables son marcadas con un signo precedente (sigil). Los sigil identifican inequívocamente los nombres de las variables, permitiendo a Perl tener una rica sintaxis. Notablemente, los sigil permiten interpolar variables directamente dentro de las cadenas de caracteres (strings). Como en los shell, Perl tiene muchas funciones integradas para tareas comunes y para acceder a los recursos del sistema. Perl toma las listas del Lisp, hash (memoria asociativa) del AWK y expresiones regulares del sed. Todo esto simplifica y facilita todas las formas del análisis sintáctico, manejo de texto y tareas de gestión de datos. En Perl 5, se añadieron características para soportar estructuras de datos complejas, funciones de primer orden (p. e. clausuras como valores) y un modelo de programación orientada a objetos. Éstos incluyen referencias, paquetes y una ejecución de métodos basada en clases y la introducción de variables de ámbito léxico, que hizo más fácil escribir código robusto (junto con el pragma strict). Una característica principal introducida en Perl 5 fue la habilidad de empaquetar código reutilizable como módulos. Larry Wall indicó más adelante que "la intención del sistema de módulos de Perl 5 era apoyar el crecimiento de la cultura Perl en vez del núcleo de Perl". Todas las versiones de Perl hacen el tipificado automático de datos y la gestión de memoria. Antonio Romero Solís Página 18

19 El intérprete conoce el tipo y requerimientos de almacenamiento de cada objeto en el programa; reserva y libera espacio para ellos según sea necesario. Las conversiones legales de tipo se hacen de forma automática en tiempo de ejecución; las conversiones ilegales son consideradas errores fatales. 5.2 Valoración de alternativas al lenguaje de implementación. Después de observar las distintas tecnologías que tenemos disponibles actualmente, y teniendo en cuenta los objetivos planteados, realizaremos a continuación una valoración de todas ellas para concluir con que posibles candidatas de las descritas anteriormente como implementaciones alternativas, es la que más se ajusta a nuestras necesidades planteadas en este proyecto. Cold Fusion podría ser una alternativa totalmente válida, ya que posee una base de trabajo bastante sólida, escalable, multiplataforma, y además proporciona herramientas muy completas y muy bien diseñadas para los desarrolladores y todas sus partes (entorno de desarrollo, servidor de aplicaciones, etc.) están perfectamente integradas. Además, su lenguaje de scripting es relativamente sencillo de aprender, sobretodo si tenemos en cuenta que contamos con el apoyo de su entorno de desarrollo, que proporciona ayudas en lo referente al diseño visual. Sin embargo, al ser una solución propietaria, su coste de implantación (entre herramientas de desarrollo y servidor de aplicaciones) puede llegar a ser bastante alto (dependiendo de la versión de Cold Fusion que necesitemos comprar). Un efecto colateral de esto es el quedarnos ligados a una tecnología concreta de una empresa concreta (en este caso, Allaire), con lo que si alguna vez queremos cambiar de entorno de desarrollo y/o de servidor de aplicaciones, no podremos al ser Cold Fusion una solución propietaria. La única alternativa viable sería cambiar de alternativa y reimplementar todo el framework. Por lo tanto, no podemos aceptar Cold Fusion. Respecto a Servlets de Sun, es un estándar de referencia que puede implementar cualquier fabricante (Sun persigue conseguir beneficios económicos a través de la certificación de compatibilidad de los servidores de aplicaciones, y no de la tecnología en sí misma), y por ello, si la usáramos, nos ligaríamos a la tecnología y no al fabricante de ésta, que es lo ideal, ya que gracias a esto, existen multitud de servidores de aplicaciones y herramientas de desarrollo de multitud de fabricantes y para multitud de plataformas (incluso muchos de ellos son Open Source). Como consecuencia de esta gran variedad, la competencia es amplia y el rendimiento y la escalabilidad de los servidores de aplicaciones cae en un rango muy amplio, de modo que podamos gastarnos lo necesario (en función del número de clientes simultáneos que queramos tener) o incluso nada si decidimos elegir una alternativa Open Source o gratuita. Además, si en algún momento sentimos la necesidad de cambiar de servidor de aplicaciones o de plataformas por cualquier motivo, sería Antonio Romero Solís Página 19

20 totalmente viable, y con coste de implantación cero, ya que cualquier Servlet funcionará en cualquier plataforma y en cualquier servidor de aplicaciones (siempre que soporte Servlets, claro está) sin necesidad ni siquiera de recompilarlo, ya que están basados en Java (y por lo tanto, tenemos portabilidad total asegurada). Otra de las grandes ventajas de esta tecnología es el estar basada en Java, ya que además de proporcionarnos la portabilidad antes comentada, también nos proporciona acceso a casi cualquier base de datos, pero también de forma portable, ya que se utiliza para acceder a ellas una tecnología denominada JDBC, que posee propiedades parecidas a ODBC de Microsoft. Por todo lo expuesto, Servlets podría ser una alternativa válida para nuestro propósito. PHP cumple con los requisitos de ser multiplataforma (hasta Internet Information Server de Microsoft puede servir este tipo de páginas). Además también es un estándar abierto (en forma de Open Source), de modo que cualquier fabricante puede añadir soporte PHP en su servidor de aplicaciones. Además su rendimiento está a la altura de las demás plataformas (como Cold Fusion y Servlets). Sin embargo, PHP tiene algunos inconvenientes que hacen que sea una alternativa poco viable para nuestros propósitos. Quizás la más importante de ella es la poca cohesión entre módulos (de hecho, PHP no poseía por si mismo capacidad para mantener sesiones hasta hace poco tiempo). Existe una gran variedad de módulos externos que hacen que PHP pueda realizar casi de todo, pero precisamente al no existir relación alguna entre los desarrolladores de los distintos módulos, tenemos una falta de cohesión muy importante y debido a ello una gran falta de centralización: si queremos realizar alguna labor relativamente compleja, necesitaremos buscar distintos módulos para realizar las distintas partes de la misma (PHP carece de API potente). Además, PHP no es orientado a objetos, tiene pocas herramientas de desarrollo y finalmente, no posee una API genérica para acceder a bases de datos, lo que nos obligaría a utilizar código específico de la misma en nuestro desarrollo, contraponiéndose este aspecto a uno de nuestros objetivos fundamentales: la portabilidad. Por lo tanto, PHP, aunque casi aceptada, ha tenido que ser rechazada por la importancia tan vital que tiene para nosotros los accesos a bases de datos y por la falta de una API. Aunque por lo que verdaderamente se ha quedado fuera ha sido por la necesidad de un lenguaje de programación relativamente potente para realizar las tareas complejas que necesitaremos. En cuanto a las distintas tecnologías ASP de Microsoft (ASP y ASP.NET), decir, que al igual que Cold Fusion, serían una alternativa totalmente válida si no fuera porque son una tecnología propietaria de una empresa y por tanto nos ceñimos a ella. Pero este caso es aún peor que el Cold Fusion si cabe, ya que las páginas ASP sólo pueden ser servidas por los servidores de aplicaciones de Microsoft, que además sólo funcionan Antonio Romero Solís Página 20

21 bajo plataformas Microsoft. Esto quiere decir que además de tener que pagar por el servidor de aplicaciones y tener todos los inconvenientes que de ello se deriva (los mismos básicamente que para Cold Fusion), tendremos que pagar por un sistema operativo Microsoft y además adecuar el hardware de las plataformas (tanto de implantación como de desarrollo) a algo que pueda funcionar con un sistema operativo Microsoft en caso de que fuera necesario. Ahora bien, si por otro lado comparamos las páginas JSP, hemos podido apreciar al describir este tipo de lenguaje de implementación, que poseen una muy buena escalabilidad tanto en el tiempo de desarrollo (lo que significa que son mejores para proyectos grandes) como en tiempo de ejecución. Si teniendo en cuenta esto, y las comparamos con las páginas ASP, ya tenemos un punto en contraste de estas páginas, y un primer punto a favor de la tecnología JSP, ya que las ASP se tienen que recompilar cada vez que se las llama, perdiendo en este caso tiempo, rendimiento y calidad. Llegando a este punto y tras explicar como por el momento JSP le gana la partida a ASP y ASP.NET, podemos concluir que estas dos últimas quedan totalmente descartadas. Analizando un poco mejor la tecnología JSP y como acabamos de decir, son una mejor alternativa a las ASP de Microsoft. Estas páginas están basadas en Servlets, y también han sido desarrolladas por Sun. De hecho, poseen todas las ventajas de los Servlets en cuanto a portabilidad y escalabilidad, y además otras muchas, como por ejemplo la separación entre presentación y código. Debido a todo esto, concluimos que esta alternativa también sirve perfectamente para nuestros propósitos. Por otro lado tenemos la tecnología XSP. Esta tecnología no ha sido muy conseguida, y como consecuencia su utilización en el mundo de las Aplicaciones Web ha sido muy negativa. Unido esto a que todavía queda mucho por estudiar y desarrollar de ella si se quiere que compita con otras más extendidas, llegamos a la conclusión de que esta también queda totalmente descartada. En cuanto a la tecnología JSF: Este patrón nos permite/obliga a separar la lógica de control (sabe qué cosas hay que hacer pero no cómo), la lógica de negocio (sabe cómo se hacen las cosas) y la lógica de presentación (sabe como interactuar con el usuario). Utilizando este tipo de patrones conseguimos: más calidad, mejor mantenibilidad, perder el miedo al folio en blanco (tengo un patrón a seguir al empezar un proyecto),... pero una de las cosas más importantes es la normalización y estandarización del desarrollo de Software. Todo esto unido a que esta tecnología, si bien se puede decir que es una evolución de los famosos Struct, nos lleva a la primera impresión de que perfectamente es posible realizar nuestro proyecto con ella. Aunque como siempre se dice no es bueno quedarse con la primera impresión. Como toda evolución y actualización en cuanto a tecnologías, siempre las primeras suelen tener diversas lagunas, y es por ellos el que los desarrolladores no empiecen a tomárselas en serio hasta que llevan un tiempo al alcance de todos. Por tanto, JSF es una buena alternativa si no fuese porque es una evolución Antonio Romero Solís Página 21

22 realmente joven y que necesita todavía de numerosas revisiones hasta adecuarla a otras tecnologías. Como consecuencia hay que razonar que no sería en tal caso tan recomendable para nuestro proyecto, y en este caso la descartamos. Ahora hablaremos de Ruby on Rails. A pesar de ser una gran tecnología hemos encontrado desventajas a la hora de utilizarla. Por ejemplo, en cuanto al código, la forma de estructurarlo, será la que el propio Framework te dicte, ya que separa en carpetas cada capa de su modelo de desarrollo. Aunque esto pueda resultar incomodo para un desarrollador experto que desee hacer las cosas "a su manera", de cara al programador novato, es una grandísima ventaja, ya que sin quererlo, tendrá el código perfectamente ordenado. Otra desventaja y esta mucho mas "preocupante", es la cantidad de hosting o empresas de alojamiento web, que ofrecen servicio con soporte para este lenguaje. Pese a que Rubi on Rails nada más salir parecía netamente mejor que otras opciones como PHP o Java, se demuestra que realmente es débil donde PHP o Java son fuertes con lo que, si es mejor que PHP o Java, lo es sólo en parte. PHP y Java han ido absorbiendo o absorberán la mayoría de las ventajas de Rubi on Rails con lo que las razones para pasarse a esta tecnología desaparecerán casi completamente. Y finalmente, respecto a Perl, es una tecnología interesante que hemos podido estudiar poco, hemos encontrado alguna que otra desventaja, sobre todo para los usuarios de Windows. Los usuarios de Microsoft Windows normalmente instalan una distribución binaria de Perl. Compilar Perl desde el fuente bajo Windows es posible, pero la mayoría de las instalaciones no disponen del necesario compilador de C. La capa de emulación Cygwin proporciona otra forma de correr Perl bajo Windows. Cygwin proporciona en entorno parecido al Unix en Windows que incluye gcc, por lo que compilar Perl desde el código es una opción accesible para los usuarios que prefieren esta opción. Sin embargo, Perl está instalado por defecto en las distribuciones más populares de GNU/Linux incluyendo Gentoo, Mandriva, Debian, RedHat y SUSE. Por otro lado, las implementaciones Perl normalmente toman más memoria que las implementaciones en otros lenguajes, y esto varía los resultados de velocidad. Las prestaciones de Perl son similares a las de otros lenguajes como Java, Python, PHP o Ruby, pero más lento que la mayor parte de lenguajes compilados. Tras analizar todas las tecnologías de implementación que podíamos haber elegido para desarrollar nuestro proyecto, hemos llegado a la siguiente conclusión: Repasando las tecnologías, nos damos cuenta de que sólo aquellas basadas en Java han sido seleccionadas. Como se puede desprender de la evaluación anterior, los Antonio Romero Solís Página 22

23 motivos por los cuales se han seleccionado han sido básicamente, el hecho de ser multiplataforma, tecnologías abiertas, escalables y coherentes, de modo que tengan un rendimiento alto y proporcionen libertad tanto a la hora de hacer el desarrollo como a la hora de hacer la implantación (en lo referente a herramientas y plataformas). La elección entre Servlets o JSP es bastante dura, ya que, en principio, no hay nada que se pueda hacer con un Servlet y que no se pueda hacer con un JSP. Pero ambos proporcionan ventajas e inconvenientes. Los JSP son más aptos para realizar diseños cambiantes, es decir, aquellos que requieren tener a un diseñador constantemente modificando el código HTML y objetos multimedia de la página, ya que JSP se desarrolló para poder separar la implementación de la presentación, de manera que se pudieran tener dos equipos de desarrollo distintos sin que interfirieran unos con otros. Sin embargo, a la hora de realizar muchas tareas complejas en el lado del servidor (control de concurrencia, control de cambios, sensibilidad...) es mejor utilizar un Servlet. El motivo principal es que el JSP puede volverse demasiado complicado si necesitamos programar mucho, ya que tendríamos que utilizar JavaBeans para encapsular comportamientos y además tratar todos los eventos dentro del mismo JSP, con lo que perdemos buena parte de la versatilidad que proporcionan éstos para separar la presentación de la programación. Además, hay tareas complejas que no podemos realizar, como por ejemplo, extender la clase Servlet para crear superclases que, por ejemplo, realicen una caché automática de las peticiones; es decir, el programador de aplicaciones pierde el control total sobre el entorno de ejecución que tiene cuando utiliza Servlets puros. Debido a todo ellos, nuestra decisión ha sido la utilización de las dos tecnologías: JSP y Servlet. Hemos llegado a la conclusión de que las dos tecnologías se complementan perfectamente a las lagunas que poseen cada una de ellas. Por un lado, para el diseño de las pantallas que dan formato a lo que más tarde visualizará el usuario utilizaremos las páginas JSP; mientras que por otro lado, utilizaremos los Servlet para el control de la Aplicación, el cual es el verdadero punto duro que tiene todo proyecto de esta envergadura. A esta utilización de las dos tecnologías conjuntamente se le conoce como modelo 2 de los JSP o modelo MVC (Modelo Vista Controlador). Antonio Romero Solís Página 23

24 5.3 Sistemas Gestores de Bases de Datos Los Sistemas de gestión de base 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. Actualmente existen muchos, algunos de ellos de pago, y otros libres, sin significar esto que éstos últimos ofrezcan menos posibilidades que los de pago. A continuación, describimos aquellos más utilizados en la actualidad por los diseñadores implementadores Web Oracle Es un Sistema de Gestión de Base de Datos relacional fabricado por la compañía Oracle Corporation. Oracle surge a finales de los 70 bajo el nombre de Relational Software a partir de un estudio sobre SGBD (Sistemas Gestores de Base de Datos) de George Koch. Computer World definió este estudio como uno de los más completos jamás escritos sobre bases de datos. Este artículo incluía una comparativa de productos que erigía a Relational Software como el más completo desde el punto de vista técnico. Esto se debía a que usaba la filosofía de las bases de datos relacionales, algo que por aquella época era todavía desconocido. Se considera a Oracle como uno de los sistemas de bases de datos más completos, destacando su: * Soporte de transacciones. * Estabilidad. * Escalabilidad * Es multiplataforma. Su mayor defecto es su enorme precio, que es de varios miles de euros (según Antonio Romero Solís Página 24