Primera práctica de la asignatura:
Sistemas Distribuidos
Curso 2005-2006
Resumen
Cierto proceso central, actúa como
servidor del tipo de recurso “Noticia”. Sobre dicho servidor lanzan peticiones dos
tipos de procesos distintos que están a las órdenes de dos tipos de principales
“Redactor” y “Lector”. El protocolo deberá dar soporte básico a las demandas
más elementales de estos dos tipos de actores. El sistema deberá estar
documentado convenientemente, y su diseño deberá implementarse en Java sobre
sockets TCP.
Requisitos
El curso pasado, se planteó como práctica un sistema donde cierto
servidor («servidor de mensajes») daba la posibilidad de que dos procesos se
enviaran mensajes uno a otro, aunque el receptor no estuviera «conectado» al
sistema en ese momento. Digamos que se
trataba de enviar un mensaje cualquiera a un receptor concreto. En esta
práctica, los papeles se invierten, tratamos de enviar un mensaje concreto a un
receptor cualquiera. Es decir, el patrón de análisis del problema es simétrico
(en cierto sentido) al anterior.
Las noticias son cadenas de bytes,
con un encabezado compuesto de un nombre único (en el servicio), una fecha de
creación, una fecha de modificación, una fecha de caducidad, y el nombre del
principal que creó la noticia. Cada vez que se transmite una noticia, ésta
viene precedida de la información de cabecera.
Obviamente, las primitivas
presentadas en el diagrama precedente, vienen soportadas por (al menos) un
servidor. Y los actores representan papeles distintos, lo cual no es obstáculo
para que un mismo principal pueda adoptar los dos papeles a la vez. Los casos
de utilización del protocolo son los siguientes:
Para el Redactor:
Agregar Noticia: Representa la acción por la
cual el Redactor crea un nuevo objeto de tipo Noticia en el servicio, y le
otorga un nombre. Queda claro que pudiera darse el caso de que el nombre ya
exista, o que el principal no esté autorizado, o …
Modificar Noticia: Para que sin necesidad de que
se cree un nuevo objeto de tipo Noticia, el Redactor pueda cambiar los
contenidos de la noticia. Véase que, de esta forma, una noticia se convierte,
en cierto modo, en un canal de comunicación. Los posibles errores son diversos.
¡Encuéntrelos!
Consultar Interés: Es una primitiva muy interesante,
y que nos permitirá dar sentido a las últimas frases del párrafo anterior. En
definitiva consiste en saber qué individuos han consultado cierta noticia.
Para el Lector:
Leer Noticia: Permitirá al Lector acceder al
contenido de la noticia, y posiblemente a algún dato adicional sobre ella. Para
que el Lector pueda acceder a la noticia, deberá conocer su nombre.
Buscar Noticias: Mediante esta primitiva, el
Lector podrá obtener un listado de noticias del servicio. En primera instancia,
esta primitiva puede ser muy sencilla, pero para los alumnos avanzados, podría
establecerse un mecanismo de filtrado sobre los datos de la cabecera, para
recuperar sólo aquellas noticias que nos interesen.
Ojo, cada primitiva se envía con una conexión de sockets independiente, como ocurre con HTTP v1.0, y hemos comentado en clase.
Puntualizaciones interesantes:
Como puede verse, este servicio requiere dos
protocolos. Y cada uno de ellos, aunque con pocas primitivas básicas, puede
irse complicando todo lo que queramos. Pero el objetivo de esta práctica es
limitado: simplificad en lo posible el protocolo, para cumplir las
especificaciones. Posteriormente, se podrá refinar, porque va a ser el germen
de la segunda práctica a realizar mediante Java RMI. (Por eso es importante
esta práctica y, por lo mismo, tampoco es tan importante).
La documentación constará de:
Un documento de análisis sencillito (un par de
carillas)
Diagramas de tipo de proceso, a placer.
Diagramas de secuencias principales.
La documentación deberá ir en html, con archivos
en jpeg, convenientemente identificada con vuestros nombres. Ya os diré más
adelante como se recogerá esta práctica.
El plazo será de, aproximadamente, un mes.
Otras puntualizaciones
La documentación anterior puede parecer prolija,
pero es, en el fondo, muy sencilla, lo importante es tener claro lo que se desea,
analizar el problema de una vez por todas, y diseñarlo probando las cosas muy
poquito a poco (es decir, incrementalmente)
Os dais cuenta para la cantidad de cosas
interesantes que puede servir un
middleware como este.