Download Implementación de un Servidor de Información en
Document related concepts
no text concepts found
Transcript
Implementación de un Servidor de Información en Internet bajo Situaciones de Carga Elevada 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 Fidel Cacheda Seijo Alberto Pan Bermúdez Lucía Ardao Rodríguez Ángel Viña Castiñeiras E-mail: {fidel, alberto, lucia, avc}@des.fi.udc.es Abstract Internet information systems are being widely used nowadays, which produces high workload situtations and easily changeable requirements. In this way, information systems should be built using a dynamic, secure and robust architecture. In this paper we present an architecture suitable for Internet information systems, distributed in three layers, which let create a more flexible and robust system. Finally, we describe the implementation details of an information system in a real highly workloaded environment. We have used new technologies to develop our system, such as Java, which allow us to create multiplatform information servers. We use a relational database management system to store the high amount of information of our system, in order to achieve a better performance. The system is nowadays working in Internet, and can be visited at: http://www.biwe.es 1. Introducción Uno de los factores determinantes en la expansión de Internet, ha sido la aparición y difusión de los servidores de información. En la actualidad los servidores de información 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 Internet, y en concreto, en el Web ha experimentado un gran impulso [1]. Un handicap importante a la hora de proporcionar servicios de información a través de Internet ha sido la integración en este entorno con 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, permitiendo el cambio de la información de forma automática e inmediata. El hecho de generar dinámicamente los contenidos de un servidor de información presenta dos ventajas a la hora de administrarlo. En primer lugar se evita la necesidad de reeditar las páginas HTML estáticas cada vez que se produce un cambio en la información que se publica en el servidor de información. Y como segunda ventaja, se encuentra el hecho de la desaparición de las páginas con información obsoleta. Estas páginas HTML generadas dinámicamente obtendrán el contenido que tienen que publicar de un sistema lógico de almacenamiento de información (bases de datos relacionales, ficheros indexados, etc.). Y esta información podrá ser presentada al usuario en base a cualquier formato predefinido. En concreto, el servidor de información aquí presentado, BIWE (Buscador en Internet de Webs Españoles) se trata de un directorio de búsquedas español. Las principales características de un buscador, como servidor de información son las siguientes: • El volumen de información manejado es de grandes dimensiones, así como muy dinámica, debido a que continuamente se están realizando modificaciones sobre los contenidos del buscador, así como inserciones de nuevos contenidos al mismo. • La carga que debe soportar un buscador de Internet es muy elevada, por la gran cantidad de usuarios que simultáneamente acceden al servidor de información. • La rapidez del buscador es fundamental, aun bajo situaciones de carga elevada, ya que a los usuarios se les debe ofrecer el servicio bajo unas restricciones temporales medianamente severas. • La robustez de un buscador en Internet es una de sus características principales, ya que es servicio de información ya que se adapta a la plataforma ya existente del cliente. Es importante notar que no es suficiente conque los servicios sean multiplataforma, también la capa de datos (gestor de bases de datos) debería de poder ser accedida de forma estándar proporcionando así al sistema independencia del gestor utilizado. fundamental que el servicio ofrecido a los usuarios sea ininterrumpido. En el siguiente apartado se describen los objetivos que se pretenden conseguir con un sistema de información de estas características. En el tercer apartado se describe la arquitectura del sistema de información, para en el apartado cuatro describir la implementación del sistema. Por último, se comentan las principales conclusiones y trabajos futuros alrededor de este tema. 2. Objetivos Un sistema de información en Internet preparado para funcionar bajo condiciones de carga alta debería satisfacer los siguientes requerimientos básicos: • Extensibilidad. El sistema debe tener una arquitectura fácilmente extensible de manera que sea sencillo añadir nuevos servicios y funcionalidades. • • Escalabilidad. El sistema debe estar preparado para crecer de manera que pueda asumir incrementos fuertes en la demanda de servicio, incremento sensible en la cantidad de contenidos ofertados, etc. sin que se degrade de forma significativa la calidad de servicio. Robustez. El sistema debe de presentar un grado alto de tolerancia a fallos y facilidad para recuperarse de los mismos. Por ejemplo, un error en un servicio del sistema no debe de amenazar el correcto funcionamiento del sistema global. • Eficiencia. El sistema debe ser capaz de responder a las consultas efectuadas de forma interactiva en tiempo real. Esto involucra utilizar técnicas eficientes de acceso a los datos que garanticen buenos niveles de servicio. • Facilidad para la administración de contenidos. En un servidor en Internet que pretende proporcionar un número importante de servicios de información a una gran cantidad de usuarios, la administración de contenidos es un tema primordial. Es fundamental poder realizar una buena gestión de los mismos, actualizaciones y reestructuraciones rápidas, fácil detección y eliminación de información obsoleta, etc. • Uso en entornos heterogéneos y multiplataforma. Si un sistema de información pretende ser utilizado como base para múltiples servicios, a menudo bajo diferentes sistemas operativos, es fundamental que el sistema sea multiplataforma para evitar recodificaciones en caso de utilización en un entorno diferente. Esto también facilita la venta a terceros del • Seguridad. Internet es una red abierta con todas las consecuencias que esto tiene para la seguridad. Además, los servicios de información en Internet se inscriben normalmente en un ámbito competitivo donde no pueden descartarse acciones de saboteo deliberado contra el servidor. El sistema debe, por tanto, estar preparado para afrontar este tipo de situaciones tanto desde el punto de vista preventivo, como desde el punto de vista de una rápida detección y solución de problemas. En muchos sistemas también deben protegerse los contenidos contra una posible captura automática de los mismos por parte de competidores. 3. Descripción de la Arquitectura La arquitectura más extendida en la actualidad en Internet para el desarrollo de servidores de información, es una arquitectura en tres capas. En los siguientes apartados se describirá, en primer lugar a alto nivel las distintas capas de la arquitectura, para a continuación describir de forma detallada las decisiones de diseño de cada una de las capas. 3.1. Arquitectura de Alto Nivel La arquitectura de tres capas en un servidor de información presenta una capa de datos, una capa de servicios y una capa cliente. La interconexión de las tres capas se puede observar en la Figura 1. CAPA DE DATOS CAPA DE SERVICIOS CAPA CLIENTE Figura 1: Arquitectura de Alto Nivel BASE DE DATOS Como se puede observar en la figura 1, la capa de datos engloba todos los componentes del sistema que almacenan los datos. Estos, como se ha comentado anteriormente, se pueden almacenar de diferentes formas, aunque la más común será usando una base de datos. Esta capa se centrara exclusivamente en el almacenamiento y acceso a los datos, concentrándose en este punto todo acceso a los datos. La capa de datos esta formada básicamente por el sistema gestor de bases de datos y un paquete encargado de aislar el acceso a los datos. La capa de servicios se encarga de ofrecer todos y cada uno de los servicios a la capa cliente, accediendo (si es necesario) a la capa de datos para recoger información archivada. Así mismo en esta capa se incluye la provisión del servicio de información en sí mismo, proporcionado probablemente a través de un servidor de Web. Esta capa está formada por todos aquellos procesos que ofrecen servicios (servidor de Web y otros servicios). Por último, la capa cliente del sistema, se encarga de mostrar a los usuarios los resultados obtenidos de la ejecución de los servicios. Para el caso de Internet esta capa estará formada básicamente por un visor de código HTML, pudiendo incluir una herramienta capaz de ejecutar applets de Java. Esta capa se encontrará presente en cada uno de los usuarios y requerirá una baja capacidad de procesamiento, siendo la capa más ligera de todas ellas. Como se puede comprobar en la figura 1, la distribución de cada una de las capas es tal que la capa de datos y de servicios se encuentran en el servidor de información, aunque no necesariamente en la misma máquina. Y como se ha indicado, la capa cliente se encuentra al nivel de usuario, en la máquina a través de la cual el usuario esté accediendo al servidor de información. Esta arquitectura en tres capas proporciona ciertas ventajas, como son la flexibilidad e independencia proporcionada entre las distintas capas. De esta forma, sólo es necesario que ambas capas se encuentren en el mismo servidor de información, pero no necesariamente en la misma máquina. Por lo tanto, es posible ubicar la capa de datos en una máquina, mientras que la capa de servicios se encuentre en una máquina diferente. Esta configuración proporciona una mayor robustez debido a que es posible realizar una replicación de los servicios y/o de los datos, siendo una capa independiente de la otra. Esta configuración proporciona una mayor robustez al sistema de información, ya que al replicar las capas se consigue una mayor solidez del sistema ante fallos eventuales de cualquiera de las máquinas en donde se encuentren tanto la capa de datos como la de servicios. 3.2. Arquitectura de Nivel Medio En esta sección se describen de forma detallada cada una de las capas, con cada uno de sus componentes y las interconexiones entre las distintas capas. La primera capa, la capa de datos está formada básicamente por un sistema gestor de bases de datos (aunque podría ser un sistema de ficheros en caso de almacenar los datos según un esquema de indexación de archivos). Para la comunicación de la capa de datos con la capa de servicio (con el componente encargado de acceder a los datos) se usa JDBC (Java DataBase Connectivity) lo que permite una total independencia entre la capa de datos y la capa de servicio, pudiendo cambiar un gestor por otro, siendo el cambio totalmente transparente para la capa de servicios. La siguiente capa, la capa de servicios está formada por un servidor de Web (elemento básico sobre el que se asientan todos los servicios), un conjunto de servicios, un módulo o framework encargado de interactuar con la capa de datos y un módulo o framework encargado de generar el código HTML necesario para comunicarse con la capa cliente. El módulo de acceso a los datos es el encargado de normalizar el acceso a los datos, siendo el único modo de acceso a los datos almacenados en la base de datos. De esta forma se permiten aislar cambios lógicos de la base de datos, frente a los servicios, con el objetivo de conseguir una mayor transparencia frente a la base de datos. El módulo de interfaz gráfica proporciona una total independencia entre los servicios y la interfaz gráfica utilizada, pudiendo incluso adaptarse esta CAPA DE DATOS GESTOR BASE DE DATOS JDBC CAPA DE SERVICIOS Figura 2: Conexión Capa de Datos – Capa de Servicios CAPA DE DATOS CAPA DE SERVICIOS MÓDULO DE ACCESO A DATOS MÓDULO DE INTERFAZ GRÁFICA SERVICIOS SERVIDOR WEB CAPA CLIENTE Figura 3: Capa de Servicios arquitectura a sistemas no particulares de Internet, simplemente cambiando el módulo de generación de la interfaz gráfica. La última capa, la capa cliente, está formada únicamente por un navegador capaz de interpretar código HTML, o con capacidad para ejecutar applets de Java [2]. Esta arquitectura hace que los servicios únicamente accedan a la capa de datos (a través de la interfaz de acceso a datos) y al módulo de interfaz gráfica, devolviendo sus resultados a la capa cliente. De esta forma es posible modificar tanto el sistema gestor de bases de datos sin necesidad de modificar los servicios, únicamente modificando el módulo de acceso a datos. De la misma forma, se puede modificar el formato de la capa cliente para que acepte otro tipo de codificación en vez de HTML, siendo únicamente necesario modificar el módulo de interfaz gráfica, lo que ofrece grandes posibilidades para la utilización de esta arquitectura en otros entornos más allá de Internet. Como ventaja adicional, por el hecho de construir los módulos de acceso a bases de datos y el módulo de la interfaz gráfica como frameworks, los desarrolladores pueden desarrollar nuevos servicios sin ningún tipo de conocimiento de la capa de datos ni de la capa de usuario. Así mismo, en caso de la utilización del sistema por otros usuarios (externos al sistema de información) podrían desarrollar servicios propios que hiciesen uso de los módulos de acceso a datos y de interfaz gráfica, pasando a estar la capa de servicios conformada por múltiples servicios, incluso en servidores. 4. Implementación Una vez analizados los módulos en los que se va a dividir la arquitectura y teniendo en cuenta los requisitos que sería recomendable que reuniese un servidor de información en situaciones de carga alta, se decide realizar la implementación de la capa de servicios utilizando el lenguaje Java. Se decide también que los servicios sean servlets JAVA en lugar de los tradicionales CGIs. En cuanto a la capa de datos se decide utilizar un SGBD relacional (los únicos con presencia significativa en el mercado hoy en día) accediendo al mismo a través del estándar JDBC que nos proporciona independencia de la Base de Datos utilizada. Para la implementación concreta del buscador de Internet BIWE basado en la arquitectura expuesta, se utiliza el gestor relacional de Oracle en su versión 7.3.3. A continuación se analizan de manera pormenorizada las razones de estas decisiones. El lenguaje Java tiene como principal característica que se puede ejecutar en varias plataformas sin tener que recompilar el código siendo únicamente necesario un intérprete de Java específico para cada plataforma. Esto nos permite obtener aplicaciones Web multiplataforma 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 sencilla y fácilmente extensible. Los marcos de trabajo (frameworks) expuestos en el apartado 3 son más fácilmente implementables con las características requeridas utilizando un lenguaje orientado a objetos como JAVA. • 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 información 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. En situaciones de carga alta como las que debe de soportar nuestro servidor de información, es fundamental que el soporte multitarea sea eficiente y sencillo de implementar. JAVA cumple ambos requisitos. • • Los mecanismos de gestión de memoria que utiliza Java, facilitan 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 ejecución lo que facilita la seguridad. La gran vitalidad que tiene en estos momentos el lenguaje JAVA (ya convertido en una plataforma de desarrollo de aplicaciones distribuidas más que un simple lenguaje) hace que tenga más extensiones y APIs para realizar aplicaciones distribuidas que cualquier otro lenguaje. Esto facilita el desarrollo de nuevos servicios de tecnología punta. La elección del uso de servlets(que podrían ser definidos como applets que se ejecutan en el servidor) para la implementación de la capa de servicios WWW viene derivada de sus importantes ventajas frente a los CGIs tradicionales: • Son una forma estándar de ejecutar programas JAVA en el servidor. Esto quiere decir que los servlets son independientes de la plataforma (por estar hechos en JAVA) y del servidor de Web utilizado (ya que son una API estándar implementada por los principales servidores de Web del mercado). • Permite multi-threading y en general tiene todas las ventajas asociadas a JAVA: robustez, seguridad, gran cantidad de extensiones y APIs para todo tipo de aplicaciones, etc. • A diferencia de los CGIs no se cargan en memoria cada vez que son invocados sino que permanecen cargados en memoria y lanzan un thread para cada petición. Esto los convierte en más eficientes. 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 con un alto grado de concurrencia. Es decir, que mediante la utilización de Java y SQL podemos implementar la arquitectura explicada anteriormente. 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 aprovechamiento de las posibilidades que ofrece cada SGBD. Por otro lado el uso de mecanismos como ODBC o JDBC proporciona independencia con respecto al SGBD de utilizado, lo que es muy importante si se pretende que los servicios estén distribuidos en entornos heterogéneos. También es importante la independencia del gestor si se pretende vender el sistema a terceros sin necesidad de tener que realizar diferentes versiones para cada gestor. En general, el uso de JDBC debe de ser la mejor opción, ya que proporciona independencia del gestor y la plataforma y, a diferencia de, por ejemplo, ODBC, su eficiencia es comparable a la de las APIs nativas. De todas maneras, en entornos donde la eficiencia sea absolutamente crítica recomendamos la realización de pruebas comparativas entre ambos métodos para el caso concreto. Para el caso del buscador BIWE, realizamos dichas pruebas y los resultados mostraron una diferencia prácticamente despreciable de eficiencia entre JDBC y las APIs nativas de ORACLE. Por tanto, nuestra elección fue el uso de JDBC. De todas maneras, el diseño modular de la arquitectura y su implementación utilizando clases de Java, nos permitiría efectuar fácilmente mejoras mediante la especialización de las clases que proporcionan el acceso al SGBD. De este modo podríamos disponer la utilización de APIs nativas, para aquellas aplicaciones en las que la diferencia en el rendimiento de ejecución fuese apreciable. En la práctica, esto no ha sido necesario para ninguna aplicación de BIWE. actualmente, que recibe del orden de 40000 accesos diarios. El diseño independiente de cada una de las capas que conforman la arquitectura provee al sistema de una gran flexibilidad e independencia entre cada una de las capas. La implementación se ha desarrollado en Java lo que otorga al sistema la capacidad de ser multiplataforma. Este servicio se http://www.biwe.es. puede visitar en: Referencias [1] J.A.O’Brien, “Introduction to Information Systems: An Internetnetworked Enterprise Perspective”, Second Alternate Edition, Ed. Irwin/McGraw-Hill, ISBN: 0-256-25196-7 [2] A. Puliafito, O. Tomarchio, L. Vita and K.S. Trivedi, “Increasing application accesibility through Java”, IEEE Internet Computing, Vol 2, No4, July 1998, pp 70-87. Figura 4: Capas de software para uso de JDBC 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ándar de Java, y está incluido en el JDK 1.1. Recientemente ha sido presentada por Java Soft la versión 1.2 del API JDBC, que mejora y extiende las capacidades de la versión 1.1. Sin embargo, se requiere ahora un tiempo de espera antes de que los fabricantes de gestores de Bases de Datos presenten drivers para sus gestores acordes con la nueva especificación. 5. Conclusiones En el presente trabajo se ha presentado una arquitectura para del desarrollo de servidores de información en Internet bajo condiciones de alto rendimiento, basado en una arquitectura en tres capas que permite la distribución de los datos y los servicios, lo que ofrece las ventajas de: • • • Robustez Fiabilidad Alto rendimiento Esta arquitectura se ha utilizado para el desarrollo de un sistema de información, en funcionamiento