Download Arquitectura Avanzada de Servidores WWW

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.