Segunda práctica de la asignatura:
Sistemas Distribuidos
Curso 2005-2006
Resumen
Esta segunda práctica resulta de
considerar la primera práctica más algunas cuestiones
que la hacen más atractiva para su diseño bajo Java RMI. Por ello, si piensa hacer
esta práctica, lea bien el primer enunciado, pues aquí haremos alguna alusión a
aquél.
Cierto proceso central, actúa como
servidor del tipo de recurso “Noticia”. Dicho servidor dispone de dos
interfaces distintas, que obedecen a dos tipos de sesiones, la sesión del
“Redactor” y la sesión del “Lector”. El servidor deberá soportar los mensajes
elementales de estos dos tipos de actores. El diseño del sistema deberá hacerse
mediante el modelo de objetos distribuidos proporcionado por Java-RMI.
Requisitos
Las noticias a las que nos referimos en
esta práctica son cadenas de bytes, con un encabezado compuesto de un nombre
único (en el servicio), un títular, 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 contiene la información de
cabecera. Obviamente, y este es un punto importante, hay que distinguir entre
el contenido de la noticia y el gestor de las noticias, lo que no resulta tan
obvio, cuando consideramos algunos casos de uso que parece que deben
implementarse en una posible clase “Noticia” (este es el caso de “Leer
Noticia”, o “Consultar Interés”).
Obviamente, los casos de uso del
diagrama precedente son soportados por la interfaz. Los casos de utilización
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.
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. Es decir debe proporcionar una lista de identificadores de Lectores
que han leído la noticia.
Para el Lector:
Leer Noticia: Permitirá al Lector acceder al
contenido de la noticia, y su cabecera. Piense en los mecanismos que tendrá que
habilitar para que un posible Lector acceda a las Noticias.
Buscar Noticias: Mediante este método, el Lector
podrá obtener un listado de noticias del servicio. El mecanismo permitirá
buscar noticias mediante criterios de fecha y palabras clave sobre el titular
de la noticia, para que así podamos recuperar sólo aquellas noticias que nos
interesen.
Registrar Interés: Mediante esta
operación, cierto método especial del Lector será invocado remotamente por el
servidor de Noticia cuando se produzca una modificación.
¡ OJITO ! : Puede que haya más de un
lector interesado por la noticia concreta, y hay que notificar a cada uno de
ellos.
Puntualizaciones interesantes:
Antes de codificar la práctica, es aconsejable
preguntar al profesor para que valide el diseño y le comente posibles fallos o
mejoras. Para ello, hay que tener en mano, al menos un diagrama de clases de diseño,
medianamente elaborado.
Para la documentación definitiva, deberá
entregar:
Un diagrama de clases para el diseño, al menos
Los programas en Java que componen la aplicación
completa.
Aquellos diagramas de secuencia o de estado que
describan vuestra aplicación.
JavaDoc de todos vuestros programas. (Un JavaDoc
decente).
El plazo será de, aproximadamente, un mes.