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