LSID
Universidad de Almería
Laboratorio de
Sistemas de Información Distribuidos

 


PRACTICAS

Práctica 1
Práctica 2
Práctica 3
 

Valid HTML 4.01 Transitional

 
 
 
 
 
 
 
 
 
 

ooooooooooooooo



Práctica 3: Productor/Consumidor CORBA bajo Web

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:

  1. Cuando la pila contiene menos de 50 elementos. En este caso solo se permite hacer llamadas al servicio put
  2. Cuando la pila contiene entre 50 y 99 elementos. En este otro caso se permite hacer llamadas a cualquiera de los tres servicios.
  3. Cuando la pila contiene 100 elementos. En este caso no se permite introducir más elementos en la pila, y solo se podrá leer el tope con read o con get.
  4. Dado que el componente CORBA es un componente independiente, la oparación put que recibe un documento XML deberá comprobar si este argumento es realmente un XML bien construido; es decir, deberá analizar (con un parser) el formato de su argumento.


LSID, Laboratorio de Sistemas de Información Distribuidos
Departamento de Lenguajes y Computación
Universidad de Almeria, España
Luis.Iribarne@ual.es