Download Arquitectura Avanzada de Servidores WWW
Document related concepts
no text concepts found
Transcript
Arquitectura Avanzada de Servidores WWW Autogestionados DEPARTAMENTO DE ELECTRÓNICA Y SISTEMAS FACULTAD DE INFORMÁTICA, UNIVERSIDAD DE A CORUÑA CAMPUS DE ELVIÑA s/n, 15.071 A CORUÑA Antonio López Fernández Rocío Paradela Guerrero Justo Hidalgo Sanz Fidel Cacheda Seijo Alberto Pan Bermúdez Angel Viña Castiñeiras Correo electrónico: {alf, rocio, justo}@cesat.es, {fidel, alberto, avc}@gris.des.fi.udc.es Abstract: Demand for Web-based aplications has undergone a spectacular increase. As a result, it's time to reconsider if present Web server models are capable of meeting the needs of those applications. This paper begins by analizing which are the demands of a dynamic web server with automatic data input and output , automatic administation systems, access statistics, and server data security. Later, an architectural model as the one described above will be introduced. We will review its functional module breakdown (access, data, management, administration, and presentation modules) and how these modules interact. Finally, there is a description of this architecture's implementation in an actual high-traffic web server. New technologies, such as Java -which allows the creation of cross-platform web servers, and the capability to run under UNIX or Windows NT- have been used in this implementation. In order for the web-server to handle high-volume information efficiently, development of this application has been built over a relational database. The aforementioned architecture has been implemented in its entirety as part of an internet search engine named BIWE (http://biwe.cesat.es). 1. Introducción Uno de los factores deterninantes en la expansión de Internet, fue la aparición y difusión de los servidores WWW. En la actualidad los servicios WWW son los más usados en Internet. Esta popularidad ha obligado a muchas empresas y organismos a prestar sus servicios a través de estos medios. Este es el motivo por el cual el desarrollo de nuevas aplicaciones basadas en el Web ha experimentado un gran impulso. Un handicap importante a la hora de proporcionar sevicios a través de Internet ha sido la integración en este entorno de las aplicaciones ya existentes. Uno de los principales problemas a la hora de ofrecer servicios basados en WWW ha sido el gran esfuerzo necesario para mantener actualizada la información publicada en los servidores Web. Un primer paso para reducir este esfuerzo es conseguir que las páginas HTML sean generadas total o parcialmente de forma dinámica. La utilización de páginas HTML dinámicas tiene dos ventajas a la hora de administrar un servidor WWW. En primer lugar evita la reedición de páginas HTML cada vez que hay un cambio en la información que se publica en el servidor. Además desaparecen las páginas con información obsoleta. Estas páginas HTML generadas dinámicamente obtendrían el contenido que tienen que publicar de un sistema lógico de almacenamiento de información (ficheros indexados, bases de datos relacionales, etc.). Esta información será presentada al usuario final preestablecido. en base a un formato La primera técnica empleada para generar páginas HTML dinámicas fue la utilización de CGIs (Common Gateway Interface). La especificación CGI define el mecanismo mediante el cual se comunican un servidor HTTP y un programa. Utilizando CGIs se permite ejecutar programas en el servidor cuyo resultado se direcciona al cliente Web a través del servidor HTTP, efectuando únicamente una impresión por la salida estándar Generalmente los CGIs suelen ser la acción o respuesta al envío de un formulario HTML al servidor WWW. La especificación CGI define como se deben pasar los campos del formulario HTML al CGI para que éste pueda procesarlos. En servidores WWW con un volumen de información a tratar pequeño o mediano, el modelo más sencillo para la implementación de un servidor WWW dinámico, consiste en la utilización de CGIs. Estos, en función de los parámetros de entrada que reciben, acceden a un conjunto de ficheros de los que obtienen la información que han de presentar al cliente WWW. Esta información suele estar indexada mediante una serie de procedimientos periódicos para aumentar el rendimiento en el acceso a los datos. Sin embargo, cuando los servidores WWW manejan grandes cantidades de datos, o información con un alto grado de interrelación, se hace imprescindible almacenar ésta en un Sistema de Gestión de Base de Datos (SGBD), al no ser los sistemas de indexación tradicionales lo suficientemente óptimos. Por tanto los CGIs deben ser capaces de acceder al SGBD para poder publicar esta información en los servidores WWW. Además de las escasas prestaciones de rendimiento, los CGIs presentan serios problemas de seguridad. Todo esto hace inviable la construcción de una aplicación WWW que procese la información de un SGBD de forma eficiente y segura utilizando esta tecnología. Para evitar las limitaciones de la tecnología CGI han surgido distintas alternativas: • Extensión del servidor HTTP mediante APIs: esta alternativa consiste en el desarrollo de las aplicaciones Web extendiendo la funcionalidad del servidor HTTP[2]. Para esto se proporciona un API (Aplication Program Interface) con el cual el desarrollador puede programar la aplicación, generar una librería, y posteriormente enlazarla dinámicamente con el servidor HTTP. La desventaja de los servidores implementados con esta tecnología es que tanto las librerías desarrolladas como el servidor HTTP comparten el mismo espacio de direcciones. Esto significa que el fallo de una librería defectuosa puede llegar a bloquear el sistema entero. • Gestor intermedio de ejecución: para evitar el problema de la ejecución en el mismo espacio de direcciones, algunos servidores HTTP utilizan un gestor intermedio de ejecución [1]. Este gestor se encarga de recibir las peticiones de ejecución, generadas por los navegadores Web, y asignárselas a las unidades de ejecución. Las unidades de ejecución, como su propio nombre indica, se encargan de ejecutar las librerías desarrolladas utilizando el API del servidor HTTP, en espacios de direcciones distintos. La arquitectura de servidor WWW que se propone a continuación se basa en la segunda de las alternativas expuestas. Una vez definida la tecnología que se va a utilizar para el funcionamiento del servidor hay que desarrollar la arquitectura del mismo para luego pasar a su implementación. Actualmente el Hardware y Software instalado en las empresas es muy diverso. A menudo han de convivir en la misma red corporativa, máquinas de distintos fabricantes y/o distinto Sistema Operativo. Por tanto, es importante que el sistema final desarrollado tenga un alto grado de portabilidad. Este ha sido un aspecto de especial importancia a la hora de elegir las soluciones tecnológicas sobre las que basa la arquitectura propuesta. 2. Descripción de la arquitectura Se ha decidido utilizar la arquitectura modular compuesta por cuatro bloques básicos, que se muestra en la figura 1. A continuación se explica brevemente en qué consiste cada módulo: • Módulo de presentación: interfaz Web entre el sistema y el usuario. • Módulo de acceso a datos: engloba todas las operaciones que se realizan sobre los datos, es decir, inserción, borrado, actualización y consulta de datos. • Módulo de gestión: información interna sobre datos diversos del Web (accesos, históricos, etc). • Módulo de administración: conjunto de herramientas útiles para el administrador del servidor Web. La divisisión en estos cuatro módulos se ha elegido por las siguientes razones: • Se utiliza un planteamiento natural del problema. • La modularidad no implica independencia absoluta. Los módulos interaccionan entre ellos y se puede reutilizar tanto el diseño como el código. • Permite la codificación con la herramienta más apropiada para cada operación dentro del servidor Web, mejorando su eficiencia y fiabilidad. • Cada módulo se puede dividir en submódulos de forma fácil y eficiente, llegando a la fase de implementación cómodamente. 2.1 Módulo de presentación A partir de este módulo se crea la interfaz gráfica que actúa como intermediaria entre el usuario del sistema de información y el sistema de acceso a datos. Tiene como característica principal Módulo de gestión Módulo de presentación Módulo de acceso a datos Módulo de administración Servidor WWW Figura 1: Diagrama de la Arquitectura su dinamismo. Las páginas HTML que van a formar parte de la interfaz no son estáticas sino que serán generadas y mostradas al usuario según las necesidades y peticiones del mismo. comercial, el tiempo medio de estancia de un producto o compañía, precios, etc. 2.2 Módulo de acceso a datos En un servidor autogestionado ideal, en ningún momento se debería necesitar la intervención del ser humano. Obviamente, en la actualidad un servidor no es capaz por sí mismo de obtener, interpretar, decidir y efectuar cambios en el aspecto gráfico de la interfaz con las tecnologías existentes, sobre todo cuando se trata de hacer cambios que afectan al diseño gráfico del servidor como por ejemplo el cambio de la imagen corporátiva de una empresa u organismo. Teniendo en cuenta estas limitaciones, lo que sí sería deseable es que esta interfaz se basase en páginas Web generadas dinámicamente a partir de una estructura que podemos denominar plantilla. Para la organización de las plantillas se puede optar por una de estas dos opciones: • La primera opción es tener una jerarquía orientada a objetos, de forma que la creación de la interfaz gráfica sea sencillamente la implementación de diferentes bloques tales que, ante el cambio de algún elemento, como por ejemplo un gráfico (el logotipo de la empresa), no sea necesaria la total reestructuración de las páginas y programas del servidor. • Una segunda opción, como extensión de la primera, es almacenar las plantillas en la propia base de datos del servidor Web. Eligiendo esta segunda opción , se consiguen tres mejoras principales: • El cambio del aspecto gráfico del servidor Web, no involucrará en ningún caso la recodificación de los programas que lo componen. Para cambiar el aspecto gráfico de todo el servidor, bastaría con reemplazar estas plantillas en la base de datos, aplicándose inmediatamente los cambios realizados a todo el servidor. • Se consigue una consistencia absoluta en estos cambios ya que todas las páginas HTML que muestra el servidor se generan dinámicamente a partir de las mismas plantillas. • El proceso de cambio de estas plantillas puede ser a su vez almacenado en la base de datos, permitiendo la realización de diferentes estadísticas e históricos. Se puede pensar, por ejemplo , en la creación de estadísticas accesos a la publicidad existente en una página Web Una vez creado el módulo de presentación, se requiere una interactividad con el usuario, darle el dinamismo necesario para que el cliente pueda comunicarse con el servidor Web. Se desea que los usuarios puedan consultar e incluso introducir información en el servidor WWW. El módulo de acceso a datos se encarga de procesar las peticiones suministradas por el usuario del Web, obtener la información solicitada y proporcionarla al módulo de presentación para que éste último se la muestre al usuario Este acceso a los datos ha de cumplir las siguientes propiedades: • Ha de ser seguro, introduciendo, si es preciso, capacidad de identificación. • La información ha de ser consistente en todo momento. Esta característica es esencial ya que esperamos y deseamos que tanto la introducción de datos como la consulta de los mismos pueda ser efectuada concurrentemente, sin producir los problemas típicos en estos casos, como pueden ser los bloqueos. • La información ha de ser automáticamente comprobada tanto sintáctica como semánticamente. • Tras la introducción de nueva información en el servidor, ésta ha de ser accesible inmediatamente, sin restringir el hecho de que más tarde pueda ser comprobada por un operario. Con la información proporcionada por este módulo se creará una página HTML dinámica en la que el cliente podrá observar la información requerida, la respuesta a una consulta, la confirmación de que el sistema ha introducido sus datos correctamente, o incluso, mensajes de error, con posibles soluciones (información adicional a añadir, p.e.). Tanto para la inserción de información en la base de datos como para el tratamiento de estos datos, se necesitan lenguajes de programación que se adecúen perfectamente a las necesidades de diseño impuestas en cada caso. Para el tratamiento de la información en una base de datos relacional, la referencia más clara es la utilización del lenguaje SQL con procedimientos almacenados. Para el tratamiento externo de datos (tanto de entrada como de salida) a este módulo, es necesario un lenguaje de alto nivel, multiplataforma... como es el caso de Java. puedan tener en condiciones normales, tales como que tan sólo el usuario poseedor de un registro determinado pueda eliminarlo. 2.3 Módulo de gestión El coste más importante de un servidor WWW convencional radica en el mantenimiento del mismo. La implementación de un servidor WWW normalmente tiene un coste relativamente bajo, tan sólo el desembolso inicial para la edición de las páginas HTML y el software necesario para publicarlas. El verdadero coste de tener un servidor WWW es el correspondiente a la persona o personas encargadas de mantener actualizada la información publicada en él. Una de las labores más tediosas suele ser la gestión de la información de accesos al servidor. En sistemas WWW tradicionales, esta información suele ser almacenada por el software especializado del servidor Web en un fichero de texto plano, que ha de ser después procesado, ya sea a mano o mediante otra herramienta para generar unos informes; lo cierto es que sería más aconsejable prescindir de la rigidez y poca integrabilidad que estas herramientas suelen imponer. Para lograrlo, se ha desarrollado este módulo de gestión: el almacenamiento de la información de acceso se realiza en el SGBD, estableciendo una relación entre la información de gestión y el objeto gestionado. Esta información puede ser fácilmente utilizada por otros módulos y/o aplicaciones para generar informes ad-hoc sobre los accesos al servidor Web, ya sea mediante estadísticas, históricos, gráficas, etc. Además, esta capacidad puede ser integrada con otros servicios, como puede ser el correo electrónico: los informes serían entonces generados automáticamente por el servidor Web cada cierto tiempo previamente establecido, para después ser enviados automáticamente a la persona y/o compañía interesada. Un ejemplo representativo es la publicidad insertada en una página Web, cuya vigencia va a depender del número de veces que un usuario externo accede a ella. Este estudio es necesario que se remita períodicamente, trabajo que el servidor puede realizar de una manera eficiente. Otro posible ejemplo es el control de accesos a determinada información total o parcialmente restringida. Ésta es una parte muy importante en la actualización automática de datos; siempre ha de haber un control humano sobre aquellas inserciones que puedan afectar al entorno de una forma más o menos grave. El sistema automático se puede encontrar con muchos problemas para restringir información con diferencias semánticas entre sus diferentes campos (p.e. la dirección no existe en una ciudad determinada, o los comentarios respecto a un tema determinado no tienen nada que ver con ese tema en cuestión), que sólo un control manual puede evitar. Aparte de la actualización anteriormente mencionada, el módulo de administración ha de permitir como mínimo las siguientes acciones: • Borrado e inserción de datos restringidos al usuario normal. • Modificación de la interfaz gráfica (nueva publicidad o logotipo, información temporal, etc). • Conocimiento de información adicional de los datos que no es accesible al resto de usuarios. Estas herramientas también han de permitir una actualización inmediata, de forma que los cambios se vean reflejados al instante en el servidor Web. De la misma forma, deben ser accesibles mediante Web, aunque de forma restringida, para que el administrador pueda realizar los cambios desde cualquier máquina que posea un navegador Web dentro de nuestra intranet, o desde Internet. Esto obliga a implementar un sistema de seguridad si cabe más efectivo, ya que con estas herramientas se puede conseguir un acceso total a la información que debe permanecer oculta para el resto de los usuarios. 3.Implementación 2.4 Módulo de administración Una vez analizados los módulos en los que se va a dividir el servidor WWW y teniendo en cuenta los requisitos que sería recomendable reuniese un servidor Web, se llega a la conclusión de que se debe implementar con un lenguaje de alto nivel, como por ejemplo Java, y almacenar la información en un SGBD, utilizando el lenguaje SQL para acceso y manipulación de esta información. El administrador ha de tener un conjunto de herramientas que le permitan tener un mayor control de la información almacenada en el SGBD que el que tiene un usuario normal. Por ejemplo, el administrador debe poder eliminar información, o modificarla, más allá de las restricciones que se El lenguaje Java tiene como principal característica que se puede ejecutar en varias plataformas sin tener que recompilar el código siendo únicamente necasario un intérprete de Java específico para cada plataforma. Esto nos permite obtener aplicaciones Web multiplatafoma con relativa sencillez. Otras ventajas que ofrece Java y que resultan útiles a la hora de implementar un servidor de las características enunciadas anteriormente, son las siguientes : • la utilización de las propiedades de herencia de clases y polimorfismo de Java, permite la implementación de la arquitectura modular descrita de forma secilla y facilmente extensible.. • la seguridad que proporciona Java es fundamental en cuanto a la privacidad de los datos que se manejan, autorización y autentificación de los usuarios a la hora de introducir cambios en la informacion que muestra el servidor y por último protección del servidor frente a las intromisiones en el sistema. • la posibilidad de implementar mediante Java la multitarea resulta de gran utilidad a la hora realizar varias acciones concurrentemente, acelerando, por tanto, la ejecución • los mecanismos de gestión de memoria que utiliza Java, facilita la labor de programación de las aplicaciones al desarrollador. También es útil el sistema de direccionamiento que tiene Java, las direcciones son simbólicas hasta el tiempo de ejecucion lo que facilita la seguridad. Estas son las principales características de Java y cubren los requisitos deseables para un servidor WWW : multiplataforma, seguridad en cuanto a los accesos al servidor y del contenido que este muestra al cliente, y multitarea. Otra de las características que debe tener un servidor Web es la consistencia de la información que almacena y muestra. Esto está garantizado organizando los datos de interés tanto del usuario como del administrador o propietario del servidor (estadísticas, históricos ... ) en un SGBD relacional y accediendo a ellos a través del lenguaje SQL. Los SGBDs permiten almacenar procedimientos SQL que se ejecuten cuando se den unas determinadas condiciones establecidas por el administrador, facilitando la autogestión del servidor. La utilización de procedimientos almacenados en el SGBD permite reducir al máximo la información que han de intercambiar cliente y servidor Web, al permitir un preprocesamiento o filtrado de la información que solicite el cliente. En los SGBD relacionales se puede proteger la información y los accesos a ésta estableciendo varios niveles de acceso y evitando bloqueos, algo fundamental en un servidor WWW de con un alto grado de concurrencia.. Es decir, que mediante la utilizacion de Java y SQL podemos implementar la arquitectura explicada anteriormente logrando un servidor WWW que se autogestione además de que cubra otros aspectos importantes para una aplicación de estas características. Desde el punto de vista de las aplicaciones Web, cuando se trabaja contra un SGBD, un factor determinante es la forma en que se realiza la conexión con el mismo. Básicamente existen dos posibilidades, utilizar los métodos de acceso nativos (APIs) al SGBD proporcionados por el fabricante, o usar algún mecanismo estándar de acceso genérico a bases de datos (ODBC Open Data Base Conectivity, JDBC, etc). A priori el uso de las APIs nativas para acceder a las bases de datos proporciona un mayor rendimiento y mejor aprovechamineto de las posibilidades que ofrece cada SGBD. Por otro lado el uso de mecanismos como ODBC o JDBC simplifica la implementación de aplicaciones que usen información proveniente de SGBDs de distintos fabricantes, permitiendo la realización de aplicaciones independientes de los SGBDs utilizados. Es necesario, por tanto, llegar a un compromiso entre rendimiento y flexibilidad. Actualmente, el diseño modular de la arquitectura y su implementación utilizando clases de Java, nos permite efectuar facilmente mejoras mediante la especialización de las clases que proporcionan el acceso al SGBD. De este modo podemos conservar la funcionalidad de acceso al SGBD utilizando APIs nativas, para aquellas aplicaciones en las que el rendimiento de ejecución sea un requisito prioritario. Una de las mejoras, en las que ya se está trabajando, consiste en extender el módulo de acceso a los datos, para permir la utilización de JDBC para acceder al SGBD en aquellas aplicaciones en las que sea necesario (figura 2). El API JDBC 1.10 (JavaSoft) define un conjunto de clases Java para representar conexiones a bases de datos, sentencias SQL, conjuntos de resultados, información de la estructura de la base de datos, etc. Esto permite al programador de Java ejecutar sentencias SQL y procesar los resultados independientemente del SGBD utilizado. JDBC es el API primaria para el acceso a bases de datos relacionales desde Java. JDBC es en la actualidad un componente estándard de Java, y está incluido en el JDK 1.1. Gracias a esta mejora la implementación final Aplicación Aplicación ENTORNO DE DESARROLLO BD API JDBC JAVA MÁQUINA VIRTUAL JAVA PLATAFORMA HW/ SW Figura 2: Capas de software para uso de JDBC de una aplicación WWW sería independiente de la plataforma hardware y software por la utilización de Java, e independiente del SGBD utilizado gracias a JDBC. 4. Conclusiones La arquitectura propuesta supone un avance en el desarrollo y mantenimiento de aplicaciones Web, mediante la integración de tecnologías tales como SGBDs o Java. El objetivo de la arquitectura consiste en facilitar la implementación de aplicaciones Web autogestionadas. La principales aportaciones de estas aplicaciones son: • automatización de los procedimientos de introducción de información, • actualización de la información en tiempo real, • generación automática de informes sobre el contenido y uso del servidor WWW. Referencias [1] M. Anand, E. chien, R. Condamoor, A. Mathaur, S. Adunuthula, S. Chou, and S. Nakhoda. “The Web Request Borker: A Framework for Distributed Web-Based Applications”. Oracle Corporation, Redwood Shores, CA. [2] “Netscape API Functions”.Netscape Communications, Mountain View, CA, 1996. Arquitectura Avanzada de Servidores WWW Autogestionados DEPARTAMENTO DE ELECTRÓNICA Y SISTEMAS FACULTAD DE INFORMÁTICA, UNIVERSIDAD DE A CORUÑA CAMPUS DE ELVIÑA s/n, 15.071 A CORUÑA Antonio López Fernández Rocío Paradela Guerrero Justo Hidalgo Sanz Fidel Cacheda Seijo Alberto Pan Bermúdez Angel Viña Castiñeiras Correo electrónico: {alf, rocio, justo}@cesat.es, {fidel, alberto, avc}@gris.des.fi.udc.es Abstract: Demand for Web-based aplications has undergone a spectacular increase. As a result, it's time to reconsider if present Web server models are capable of meeting the needs of those applications. This paper begins by analizing which are the demands of a dynamic web server with automatic data input and output , automatic administation systems, access statistics, and server data security. Later, an architectural model as the one described above will be introduced. We will review its functional module breakdown (access, data, management, administration, and presentation modules) and how these modules interact. Finally, there is a description of this architecture's implementation in an actual high-traffic web server. New technologies, such as Java -which allows the creation of cross-platform web servers, and the capability to run under UNIX or Windows NT- have been used in this implementation. In order for the web-server to handle high-volume information efficiently, development of this application has been built over a relational database. The aforementioned architecture has been implemented in its entirety as part of an internet search engine named BIWE (http://biwe.cesat.es). 1. Introducción Uno de los factores deterninantes en la expansión de Internet, fue la aparición y difusión de los servidores WWW. En la actualidad los servicios WWW son los más usados en Internet. Esta popularidad ha obligado a muchas empresas y organismos a prestar sus servicios a través de estos medios. Este es el motivo por el cual el desarrollo de nuevas aplicaciones basadas en el Web ha experimentado un gran impulso. Un handicap importante a la hora de proporcionar sevicios a través de Internet ha sido la integración en este entorno de las aplicaciones ya existentes. Uno de los principales problemas a la hora de ofrecer servicios basados en WWW ha sido el gran esfuerzo necesario para mantener actualizada la información publicada en los servidores Web. Un primer paso para reducir este esfuerzo es conseguir que las páginas HTML sean generadas total o parcialmente de forma dinámica. La utilización de páginas HTML dinámicas tiene dos ventajas a la hora de administrar un servidor WWW. En primer lugar evita la reedición de páginas HTML cada vez que hay un cambio en la información que se publica en el servidor. Además desaparecen las páginas con información obsoleta. Estas páginas HTML generadas dinámicamente obtendrían el contenido que tienen que publicar de un sistema lógico de almacenamiento de información (ficheros indexados, bases de datos relacionales, etc.). Esta información será presentada al usuario final preestablecido. en base a un formato La primera técnica empleada para generar páginas HTML dinámicas fue la utilización de CGIs (Common Gateway Interface). La especificación CGI define el mecanismo mediante el cual se comunican un servidor HTTP y un programa. Utilizando CGIs se permite ejecutar programas en el servidor cuyo resultado se direcciona al cliente Web a través del servidor HTTP, efectuando únicamente una impresión por la salida estándar Generalmente los CGIs suelen ser la acción o respuesta al envío de un formulario HTML al servidor WWW. La especificación CGI define como se deben pasar los campos del formulario HTML al CGI para que éste pueda procesarlos. En servidores WWW con un volumen de información a tratar pequeño o mediano, el modelo más sencillo para la implementación de un servidor WWW dinámico, consiste en la utilización de CGIs. Estos, en función de los parámetros de entrada que reciben, acceden a un conjunto de ficheros de los que obtienen la información que han de presentar al cliente WWW. Esta información suele estar indexada mediante una serie de procedimientos periódicos para aumentar el rendimiento en el acceso a los datos. Sin embargo, cuando los servidores WWW manejan grandes cantidades de datos, o información con un alto grado de interrelación, se hace imprescindible almacenar ésta en un Sistema de Gestión de Base de Datos (SGBD), al no ser los sistemas de indexación tradicionales lo suficientemente óptimos. Por tanto los CGIs deben ser capaces de acceder al SGBD para poder publicar esta información en los servidores WWW. Además de las escasas prestaciones de rendimiento, los CGIs presentan serios problemas de seguridad. Todo esto hace inviable la construcción de una aplicación WWW que procese la información de un SGBD de forma eficiente y segura utilizando esta tecnología. Para evitar las limitaciones de la tecnología CGI han surgido distintas alternativas: • Extensión del servidor HTTP mediante APIs: esta alternativa consiste en el desarrollo de las aplicaciones Web extendiendo la funcionalidad del servidor HTTP[2]. Para esto se proporciona un API (Aplication Program Interface) con el cual el desarrollador puede programar la aplicación, generar una librería, y posteriormente enlazarla dinámicamente con el servidor HTTP. La desventaja de los servidores implementados con esta tecnología es que tanto las librerías desarrolladas como el servidor HTTP comparten el mismo espacio de direcciones. Esto significa que el fallo de una librería defectuosa puede llegar a bloquear el sistema entero. • Gestor intermedio de ejecución: para evitar el problema de la ejecución en el mismo espacio de direcciones, algunos servidores HTTP utilizan un gestor intermedio de ejecución [1]. Este gestor se encarga de recibir las peticiones de ejecución, generadas por los navegadores Web, y asignárselas a las unidades de ejecución. Las unidades de ejecución, como su propio nombre indica, se encargan de ejecutar las librerías desarrolladas utilizando el API del servidor HTTP, en espacios de direcciones distintos. La arquitectura de servidor WWW que se propone a continuación se basa en la segunda de las alternativas expuestas. Una vez definida la tecnología que se va a utilizar para el funcionamiento del servidor hay que desarrollar la arquitectura del mismo para luego pasar a su implementación. Actualmente el Hardware y Software instalado en las empresas es muy diverso. A menudo han de convivir en la misma red corporativa, máquinas de distintos fabricantes y/o distinto Sistema Operativo. Por tanto, es importante que el sistema final desarrollado tenga un alto grado de portabilidad. Este ha sido un aspecto de especial importancia a la hora de elegir las soluciones tecnológicas sobre las que basa la arquitectura propuesta. 2. Descripción de la arquitectura Se ha decidido utilizar la arquitectura modular compuesta por cuatro bloques básicos, que se muestra en la figura 1. A continuación se explica brevemente en qué consiste cada módulo: • Módulo de presentación: interfaz Web entre el sistema y el usuario. • Módulo de acceso a datos: engloba todas las operaciones que se realizan sobre los datos, es decir, inserción, borrado, actualización y consulta de datos. • Módulo de gestión: información interna sobre datos diversos del Web (accesos, históricos, etc). • Módulo de administración: conjunto de herramientas útiles para el administrador del servidor Web. La divisisión en estos cuatro módulos se ha elegido por las siguientes razones: • Se utiliza un planteamiento natural del problema. • La modularidad no implica independencia absoluta. Los módulos interaccionan entre ellos y se puede reutilizar tanto el diseño como el código. • Permite la codificación con la herramienta más apropiada para cada operación dentro del servidor Web, mejorando su eficiencia y fiabilidad. • Cada módulo se puede dividir en submódulos de forma fácil y eficiente, llegando a la fase de implementación cómodamente. 2.1 Módulo de presentación A partir de este módulo se crea la interfaz gráfica que actúa como intermediaria entre el usuario del sistema de información y el sistema de acceso a datos. Tiene como característica principal Módulo de gestión Módulo de presentación Módulo de acceso a datos Módulo de administración Servidor WWW Figura 1: Diagrama de la Arquitectura su dinamismo. Las páginas HTML que van a formar parte de la interfaz no son estáticas sino que serán generadas y mostradas al usuario según las necesidades y peticiones del mismo. comercial, el tiempo medio de estancia de un producto o compañía, precios, etc. 2.2 Módulo de acceso a datos En un servidor autogestionado ideal, en ningún momento se debería necesitar la intervención del ser humano. Obviamente, en la actualidad un servidor no es capaz por sí mismo de obtener, interpretar, decidir y efectuar cambios en el aspecto gráfico de la interfaz con las tecnologías existentes, sobre todo cuando se trata de hacer cambios que afectan al diseño gráfico del servidor como por ejemplo el cambio de la imagen corporátiva de una empresa u organismo. Teniendo en cuenta estas limitaciones, lo que sí sería deseable es que esta interfaz se basase en páginas Web generadas dinámicamente a partir de una estructura que podemos denominar plantilla. Para la organización de las plantillas se puede optar por una de estas dos opciones: • La primera opción es tener una jerarquía orientada a objetos, de forma que la creación de la interfaz gráfica sea sencillamente la implementación de diferentes bloques tales que, ante el cambio de algún elemento, como por ejemplo un gráfico (el logotipo de la empresa), no sea necesaria la total reestructuración de las páginas y programas del servidor. • Una segunda opción, como extensión de la primera, es almacenar las plantillas en la propia base de datos del servidor Web. Eligiendo esta segunda opción , se consiguen tres mejoras principales: • El cambio del aspecto gráfico del servidor Web, no involucrará en ningún caso la recodificación de los programas que lo componen. Para cambiar el aspecto gráfico de todo el servidor, bastaría con reemplazar estas plantillas en la base de datos, aplicándose inmediatamente los cambios realizados a todo el servidor. • Se consigue una consistencia absoluta en estos cambios ya que todas las páginas HTML que muestra el servidor se generan dinámicamente a partir de las mismas plantillas. • El proceso de cambio de estas plantillas puede ser a su vez almacenado en la base de datos, permitiendo la realización de diferentes estadísticas e históricos. Se puede pensar, por ejemplo , en la creación de estadísticas accesos a la publicidad existente en una página Web Una vez creado el módulo de presentación, se requiere una interactividad con el usuario, darle el dinamismo necesario para que el cliente pueda comunicarse con el servidor Web. Se desea que los usuarios puedan consultar e incluso introducir información en el servidor WWW. El módulo de acceso a datos se encarga de procesar las peticiones suministradas por el usuario del Web, obtener la información solicitada y proporcionarla al módulo de presentación para que éste último se la muestre al usuario Este acceso a los datos ha de cumplir las siguientes propiedades: • Ha de ser seguro, introduciendo, si es preciso, capacidad de identificación. • La información ha de ser consistente en todo momento. Esta característica es esencial ya que esperamos y deseamos que tanto la introducción de datos como la consulta de los mismos pueda ser efectuada concurrentemente, sin producir los problemas típicos en estos casos, como pueden ser los bloqueos. • La información ha de ser automáticamente comprobada tanto sintáctica como semánticamente. • Tras la introducción de nueva información en el servidor, ésta ha de ser accesible inmediatamente, sin restringir el hecho de que más tarde pueda ser comprobada por un operario. Con la información proporcionada por este módulo se creará una página HTML dinámica en la que el cliente podrá observar la información requerida, la respuesta a una consulta, la confirmación de que el sistema ha introducido sus datos correctamente, o incluso, mensajes de error, con posibles soluciones (información adicional a añadir, p.e.). Tanto para la inserción de información en la base de datos como para el tratamiento de estos datos, se necesitan lenguajes de programación que se adecúen perfectamente a las necesidades de diseño impuestas en cada caso. Para el tratamiento de la información en una base de datos relacional, la referencia más clara es la utilización del lenguaje SQL con procedimientos almacenados. Para el tratamiento externo de datos (tanto de entrada como de salida) a este módulo, es necesario un lenguaje de alto nivel, multiplataforma... como es el caso de Java. puedan tener en condiciones normales, tales como que tan sólo el usuario poseedor de un registro determinado pueda eliminarlo. 2.3 Módulo de gestión El coste más importante de un servidor WWW convencional radica en el mantenimiento del mismo. La implementación de un servidor WWW normalmente tiene un coste relativamente bajo, tan sólo el desembolso inicial para la edición de las páginas HTML y el software necesario para publicarlas. El verdadero coste de tener un servidor WWW es el correspondiente a la persona o personas encargadas de mantener actualizada la información publicada en él. Una de las labores más tediosas suele ser la gestión de la información de accesos al servidor. En sistemas WWW tradicionales, esta información suele ser almacenada por el software especializado del servidor Web en un fichero de texto plano, que ha de ser después procesado, ya sea a mano o mediante otra herramienta para generar unos informes; lo cierto es que sería más aconsejable prescindir de la rigidez y poca integrabilidad que estas herramientas suelen imponer. Para lograrlo, se ha desarrollado este módulo de gestión: el almacenamiento de la información de acceso se realiza en el SGBD, estableciendo una relación entre la información de gestión y el objeto gestionado. Esta información puede ser fácilmente utilizada por otros módulos y/o aplicaciones para generar informes ad-hoc sobre los accesos al servidor Web, ya sea mediante estadísticas, históricos, gráficas, etc. Además, esta capacidad puede ser integrada con otros servicios, como puede ser el correo electrónico: los informes serían entonces generados automáticamente por el servidor Web cada cierto tiempo previamente establecido, para después ser enviados automáticamente a la persona y/o compañía interesada. Un ejemplo representativo es la publicidad insertada en una página Web, cuya vigencia va a depender del número de veces que un usuario externo accede a ella. Este estudio es necesario que se remita períodicamente, trabajo que el servidor puede realizar de una manera eficiente. Otro posible ejemplo es el control de accesos a determinada información total o parcialmente restringida. Ésta es una parte muy importante en la actualización automática de datos; siempre ha de haber un control humano sobre aquellas inserciones que puedan afectar al entorno de una forma más o menos grave. El sistema automático se puede encontrar con muchos problemas para restringir información con diferencias semánticas entre sus diferentes campos (p.e. la dirección no existe en una ciudad determinada, o los comentarios respecto a un tema determinado no tienen nada que ver con ese tema en cuestión), que sólo un control manual puede evitar. Aparte de la actualización anteriormente mencionada, el módulo de administración ha de permitir como mínimo las siguientes acciones: • Borrado e inserción de datos restringidos al usuario normal. • Modificación de la interfaz gráfica (nueva publicidad o logotipo, información temporal, etc). • Conocimiento de información adicional de los datos que no es accesible al resto de usuarios. Estas herramientas también han de permitir una actualización inmediata, de forma que los cambios se vean reflejados al instante en el servidor Web. De la misma forma, deben ser accesibles mediante Web, aunque de forma restringida, para que el administrador pueda realizar los cambios desde cualquier máquina que posea un navegador Web dentro de nuestra intranet, o desde Internet. Esto obliga a implementar un sistema de seguridad si cabe más efectivo, ya que con estas herramientas se puede conseguir un acceso total a la información que debe permanecer oculta para el resto de los usuarios. 3.Implementación 2.4 Módulo de administración Una vez analizados los módulos en los que se va a dividir el servidor WWW y teniendo en cuenta los requisitos que sería recomendable reuniese un servidor Web, se llega a la conclusión de que se debe implementar con un lenguaje de alto nivel, como por ejemplo Java, y almacenar la información en un SGBD, utilizando el lenguaje SQL para acceso y manipulación de esta información. El administrador ha de tener un conjunto de herramientas que le permitan tener un mayor control de la información almacenada en el SGBD que el que tiene un usuario normal. Por ejemplo, el administrador debe poder eliminar información, o modificarla, más allá de las restricciones que se El lenguaje Java tiene como principal característica que se puede ejecutar en varias plataformas sin tener que recompilar el código siendo únicamente necasario un intérprete de Java específico para cada plataforma. Esto nos permite obtener aplicaciones Web multiplatafoma con relativa sencillez. Otras ventajas que ofrece Java y que resultan útiles a la hora de implementar un servidor de las características enunciadas anteriormente, son las siguientes : • la utilización de las propiedades de herencia de clases y polimorfismo de Java, permite la implementación de la arquitectura modular descrita de forma secilla y facilmente extensible.. • la seguridad que proporciona Java es fundamental en cuanto a la privacidad de los datos que se manejan, autorización y autentificación de los usuarios a la hora de introducir cambios en la informacion que muestra el servidor y por último protección del servidor frente a las intromisiones en el sistema. • la posibilidad de implementar mediante Java la multitarea resulta de gran utilidad a la hora realizar varias acciones concurrentemente, acelerando, por tanto, la ejecución • los mecanismos de gestión de memoria que utiliza Java, facilita la labor de programación de las aplicaciones al desarrollador. También es útil el sistema de direccionamiento que tiene Java, las direcciones son simbólicas hasta el tiempo de ejecucion lo que facilita la seguridad. Estas son las principales características de Java y cubren los requisitos deseables para un servidor WWW : multiplataforma, seguridad en cuanto a los accesos al servidor y del contenido que este muestra al cliente, y multitarea. Otra de las características que debe tener un servidor Web es la consistencia de la información que almacena y muestra. Esto está garantizado organizando los datos de interés tanto del usuario como del administrador o propietario del servidor (estadísticas, históricos ... ) en un SGBD relacional y accediendo a ellos a través del lenguaje SQL. Los SGBDs permiten almacenar procedimientos SQL que se ejecuten cuando se den unas determinadas condiciones establecidas por el administrador, facilitando la autogestión del servidor. La utilización de procedimientos almacenados en el SGBD permite reducir al máximo la información que han de intercambiar cliente y servidor Web, al permitir un preprocesamiento o filtrado de la información que solicite el cliente. En los SGBD relacionales se puede proteger la información y los accesos a ésta estableciendo varios niveles de acceso y evitando bloqueos, algo fundamental en un servidor WWW de con un alto grado de concurrencia.. Es decir, que mediante la utilizacion de Java y SQL podemos implementar la arquitectura explicada anteriormente logrando un servidor WWW que se autogestione además de que cubra otros aspectos importantes para una aplicación de estas características. Desde el punto de vista de las aplicaciones Web, cuando se trabaja contra un SGBD, un factor determinante es la forma en que se realiza la conexión con el mismo. Básicamente existen dos posibilidades, utilizar los métodos de acceso nativos (APIs) al SGBD proporcionados por el fabricante, o usar algún mecanismo estándar de acceso genérico a bases de datos (ODBC Open Data Base Conectivity, JDBC, etc). A priori el uso de las APIs nativas para acceder a las bases de datos proporciona un mayor rendimiento y mejor aprovechamineto de las posibilidades que ofrece cada SGBD. Por otro lado el uso de mecanismos como ODBC o JDBC simplifica la implementación de aplicaciones que usen información proveniente de SGBDs de distintos fabricantes, permitiendo la realización de aplicaciones independientes de los SGBDs utilizados. Es necesario, por tanto, llegar a un compromiso entre rendimiento y flexibilidad. Actualmente, el diseño modular de la arquitectura y su implementación utilizando clases de Java, nos permite efectuar facilmente mejoras mediante la especialización de las clases que proporcionan el acceso al SGBD. De este modo podemos conservar la funcionalidad de acceso al SGBD utilizando APIs nativas, para aquellas aplicaciones en las que el rendimiento de ejecución sea un requisito prioritario. Una de las mejoras, en las que ya se está trabajando, consiste en extender el módulo de acceso a los datos, para permir la utilización de JDBC para acceder al SGBD en aquellas aplicaciones en las que sea necesario (figura 2). El API JDBC 1.10 (JavaSoft) define un conjunto de clases Java para representar conexiones a bases de datos, sentencias SQL, conjuntos de resultados, información de la estructura de la base de datos, etc. Esto permite al programador de Java ejecutar sentencias SQL y procesar los resultados independientemente del SGBD utilizado. JDBC es el API primaria para el acceso a bases de datos relacionales desde Java. JDBC es en la actualidad un componente estándard de Java, y está incluido en el JDK 1.1. Gracias a esta mejora la implementación final Aplicación Aplicación ENTORNO DE DESARROLLO BD API JDBC JAVA MÁQUINA VIRTUAL JAVA PLATAFORMA HW/ SW Figura 2: Capas de software para uso de JDBC de una aplicación WWW sería independiente de la plataforma hardware y software por la utilización de Java, e independiente del SGBD utilizado gracias a JDBC. 4. Conclusiones La arquitectura propuesta supone un avance en el desarrollo y mantenimiento de aplicaciones Web, mediante la integración de tecnologías tales como SGBDs o Java. El objetivo de la arquitectura consiste en facilitar la implementación de aplicaciones Web autogestionadas. La principales aportaciones de estas aplicaciones son: • automatización de los procedimientos de introducción de información, • actualización de la información en tiempo real, • generación automática de informes sobre el contenido y uso del servidor WWW. Referencias [1] M. Anand, E. chien, R. Condamoor, A. Mathaur, S. Adunuthula, S. Chou, and S. Nakhoda. “The Web Request Borker: A Framework for Distributed Web-Based Applications”. Oracle Corporation, Redwood Shores, CA. [2] “Netscape API Functions”.Netscape Communications, Mountain View, CA, 1996.