| Puesto que el examen de la asignatura es el 11 de Septiembre, por la tarde, esta práctica se recogerá, como más tarde, martes 9 de Septiembre. La recepción de las prácticas se hará por correo electrónico o por disquete, (en el primer caso se ruega que confirmen con el profesor la recepción de la práctica). Todo esto sin perjuicio de que el profesor pueda requerir el alumno las explicaciones que considere oportunas sobre el funcionamiento de la solución a la práctica. Las prácticas se entregarán por parejas o individualmente, y son una condición imprescindible para obtener resultados positivos en la convocatoria ordinaria correspondiente. |
Dado que nos vemos en la obligación de confeccionar un trabajo práctico que tenga que ver con la práctica anterior, complicaremos (aunque muy ligeramente) la segunda práctica de la convocatoria ordinaria para que podáis demostrar vuestros conocimientos sobre Java RMI. Al igual que en la segunda práctica, gozareis de libertad para hacer un diseño propio. Y también habrá unos requisitos arquitectónicos adicionales.
La cuestión consiste en fabricar un anillo de objetos distribuidos. Los clientes podrán encadenar sus objetos remotos al anillo, sin más complicaciones, de modo que sus posibilidades podrán ser muy diversas. En este momento solo nos interesa cómo resolvemos el problema del encadenamiento.
El sistema debe ceñirse a la arquitectura cliente-servidor basada en objetos, con soporte Java-RMI sobre TCP/IP.
El mecanismo de publicación de preguntas sobre nombres de anillo se ciñe a un modelo tipo pull (es decir basándose en el mecanismo de publicación de mensajes resuelto en la práctica anterior).
Concretamente, habrá que utilizar el sistema que habeis construido en la práctica anterior.
Las invocaciones y respuestas a métodos remotos irán sincronizadas con el reloj lógico de la práctica anterior.
El mecanismo de paso de «testigo» debe ser extensible, de modo que se puedan extender las clases para que el «mensaje» pueda ser capturado por el objeto como dato de algún procesamiento, e incluso ser cambiado en el interín.
No voy a especificar el protocolo que debeis de usar para el mecanismo de publicación. No voy a especificar las clases ni las interfaces.
La documentación del código deberá ir en JavaDoc. La documentación de la práctica deberá incluir diagramas de casos de uso, de clases y de secuencia correspondientes, y las plantillas que creáis convenientes. Esta documentación se entregará en formato html.
Como es muy probable que haya que añadir algún tipo de información adicional para el desenvolvimiento de la práctica, se notificarán los cambios o adiciones en el foro de la asignatura.
Este enunciado corresponde a una práctica de Sistemas Distribuidos de la Ingeniería Técnica en Informática de Gestión y Sistemas de la Universidad de Valladolid, del curso 2002-2003. Y el derecho de copia y explotación (c) me pertenece a mí (el profesor de la asignatura) y a mis alumnos :-)