DESCRIPCION
DEL PROBLEMA
En esta práctica vamos
a trabajar bajo un entorno de programación Web para desarrollar
un componente software que ofrece servicio de buffering por
Internet.
La finalidad de esta práctica es utilizar y combinar diferentes
técnicas de programación Web que puedan servirnos para
desarrollar
futuras aplicaciones Web. En la figura siguiente se muestra la
arquitectura
general del entorno que vamos a desarrollar.
<VER>
Figura 1. Arquitectura
de la práctica 3.
Como podemos ver en la figura,
nuestro entorno de trabajo está compuesto de distintas
técnicas
que se utilizan para llegar a obtener nuestro propósito: el
componente
CORBA. Como hemos adelantado, este componente realiza las tareas
de servicio de buffering. Este clase de componente tiene asociado un
buffer sobre
el que operan dos servicios, conocidos por los clientes que luego
usarán
dicho componente. Estos dos servicios son, put
para almacenar un
elemento y get para extraer un elemento.
Los servicios put
y get
del componente serán llamados desde una página Web por
dos
tipos de clientes, clientes que generan elementos (también
llamados productores),
y otros clientes que consumen elementos (llamados consumidores).
A este tipo de marco donde aparecen los tres roles (servicio de
buffering,
el productor y el consumidor) se le conoce como técnica del
"Productor/Consumidor''.
Los diferentes niveles de
nuestro ejemplo son:
Lado cliente
En el lado cliente vamos
a desarrollar dos clases de clientes. Aquellos que desean generar
(producir)
elementos y dárselos al servicio de buffering para que
éste luego los
almacene
en el buffer interno. Y los clientes que desean obtener (consumir) el
elemento.
En nuestro caso para desarrollar este nivel haremos uso de HTML que
hace
llamada GET o POST a una servlet que hay en el seguno nivel.
Supondremos que un cliente puede funcionar tanto como productor
como consumidor. La lógica de presentación del lado
clienteo se podrá desarrollar o con dos páginas HTML o
las dos opciones en una sola.
Un cliente productor deberá ofrecer
un identificador y el dato que desea producir (almacenar en el buffer).
Supondremos que el identificador será una direccion de correo
(la del productor) y el dato una cadna. La página HTML del
Productor por tanto, podria contener un area de texto para introducir
el email y otra para el dato (la cadena). El formato de la
página es libre.
Capa intermedia (Servlet)
Existen dos posibilidades: (A) Desarrollar
dos servlets para atender por separado a los dos tipos de clientes
comentados
anteriormente; y (B) Desarrollar solo un programa servlet que gestione
tanto las llamadas Productor como las de Consumidor.
En el caso del productor, el programa
servlet recibirá los dos elementos (el email y el dato) a
través de una llamada desde la página HTML. El programa
servlet tendrá que extraer los datos de la página HTML y
generar un documento XML con estos elementos.
Por ejemplo algo así.
<mensaje>
<email>un@email.es</email>
<elemento>Aqui el contenido del elemento</elemento>
</mensaje>
Este nuevo elemento XML (que encapsula los
dos datos original) es el que luego se usa como dato de intercambio con
el componente CORBA, componente que controla el buffer. Una vez
almacenado
el elemento, se debería "arrastrar" mensajes del resultado de
operacion hacia el cliente; es decir, del componente CORBA hacia el
programa servlet y desde el programa servlet hacia el cliente en HTML.
Por ejemplo, supongamos que el programa servlet ya ha generado el
documento XML. El programa se conecta con el objeto CORBA y realiza una
llamada pertinente a la operacion del objeto que permite almacenar el
documento XML. El objeto CORBA acepta dicho documento y procede para su
almacenamiento en el buffer. Si la operacion de almacenamiento se ha
llevado con exito, el componente CORBA devolvería un mensaje de
exito hacia el programa servlet y este a su vez generaría la
página HTML correspondiente para advertir al cliente del exito
de la operacion. Algo parecido debería ocurrir en caso de fallo.
Para el caso de un cliente consumidor el proceso sería algo
parecido que para el productor, solo que el documento XML se genera
ahora en el lado servidor (componente CORBA) y no en el lado
intermendio (servlet).
Por tanto, ya sea desde un cliente productor como de un cliente
consumidor, siempre se parte de dos datos (el email y el dato
producido/consumido) que hay que empaquetar-transmitir-desempaquetar.
La opcion empaquetar/seempaquetar se refiere la generacion del
documento XML a partir de los elementos, y la operacion de
desempaquetar se referira al caso inverso, extraer los dos elementos a
partir del documento XML.
En el caso del productor, el programa servlet empaqueta los elementos y
el componente CORBA los desempaqueta para al almacenarlos en un buffer
con dos campos cada celda del buffer. En el caso del consumidor es el
componente CORBA el que empaqueta ahora los elementos y luego el
programa servlet el que los desempaqueta para generar una página
HTML de respuesta.
Para
trabajar
con XML podemos hacer uso de cualquier parser XML para Java. Por
ejemplo,
para nuestro ejercicio haremos uso de XML4J de IBM, o tambien puede ser
válido JAXP de Sun.
Para hacer esta parte de
la práctica haremos uso de Tomcat como servidor Web para
registrar
las servlets. Los sockets serán implemetados con las utilidades
internas que proporciona Java, y haremos uso de una version Java de Sun.
Capa servidor (el componente)
Por último, como
implementación
de la lógica de negocio del lado servidor, tendremos el
componente
CORBA que ofrece el servicio de buffering.
Como hemos adelantado anteriormente,
componente de buffering ofrece dos servicios públicos, conocidos
y
accesibles.
Uno para almacenar un elemento, y que lo vamos a llamar put,
y otro para extraer un elemento, que lo vamos a llamar get.
Pero vamos a incorporar un
grado más de complejidad al ejercicio. Vamos a permitir que un
cliente
Consumidor pueda ver el elemento antes de consumirlo. Para lo cual
incorporaremos
un tercer servicio para el componente CORBA, que lo llamaremos read.
Además, también
vamos a incorporar ciertas restricciones de acceso para nuestro
componente.
Estas restricciones son como las que se ofrecen en el libro "Sistemas
de
Información Distribuidos" (ver capítulo 3).
REQUISITOS
DEL OBJETO BUFFER
El componente es una pila
estilo FIFO. El servicio put
incorpora un elemento en el tope de la pila, el servicio get
elimina el último elemento y devuelve su valor, y por
último
el servicio read
obtiene el valor de la pila pero sin llegar a eliminarlo de la misma.
El
estado interno de la pila puede quedar caracterizado por tres fases: