Segunda práctica de la asignatura: Sistemas Distribuidos

Curso 2003-2004

 

Resumen

Se toma como base la solución al enunciado de la primera práctica de este curso. Al contemplar la posibilidad de incluir devoluciones de llamada (callbacks) en nuestra aplicación, podemos establecer un flujo de información desde el servidor hacia el cliente que podemos utilizar para ampliar la funcionalidad de los objetos remotos de tipo "cuenta".

El estado de nuestros objetos cuenta se reduce, en esencia, a un valor numérico que expresa el saldo existente. Una posibilidad podría ser programar un único callback que notificara al cliente cuándo aparece algún cambio en este saldo, con el fin de realizar, posteriormente, un ingreso o una retirada de efectivo. Otra posibilidad es incluir callbacks variados de forma más selectiva. Esta va a ser nuestra propuesta.
Requisitos Generales:

*      Además de la interfaz establecida en la práctica anterior, debemos incluir tres métodos adicionales; a saber:

*      Un método para registrar un callback que será invocado cuando el saldo sea inferior a cierto valor (que será pasado también como argumento).

*      Un método para registrar un callback que será invocado cuando el saldo sea superior a cierto valor (que será pasado también como argumento).

*      Un método para desregistrar callbacks.

*      El cajero tendrá también algunos métodos adicionales:

*      Un método para hacer una transferencia de fondos hacia otra cuenta, que se puede retrasar en el tiempo, hasta que haya saldo suficiente para la transferencia. Por ejemplo, para pasar el efectivo hacia una cuenta con una mejor remuneración.
Solo puede haber una transferencia diferida de este tipo.

*      Un método para hacer una transferencia de fondos desde otra cuenta hacia ésta, que se puede retrasar en el tiempo, y que solo se realizará si el saldo desciende por debajo de cierto valor. Por ejemplo, para evitar descubiertos, o para realizar pagos automáticos.
Solo puede haber una transferencia diferida de este tipo.

*      NOTA IMPORTANTE: estas transferencias diferidas deberán estar soportadas únicamente por el método de transferencia ya construido en la primera práctica, y que se supone es lo suficientemente robusto.

*      Las transferencias diferidas compiten por el saldo en igualdad de condiciones que el resto de transferencias y operaciones sobre las cuentas con la interfaz cuenta.

*      Una posibilidad adicional es incluir colas de transferencias diferidas. En este caso debería optarse por una politica de servicio a las transferencias. La más sencilla es por orden de llegada, aunque podría haber otras políticas, como por ejemplo, que la transferencia fuera realizable, que fuera prioritaria, etc.
Esta característica de la práctica no es obligatoria.

Requisitos:

*      Los objetos cuenta deberán funcionar perfectamente en el caso de que los clientes no hayan incluido ningún callback.

*      Los callbacks son registrados por los objetos cajero de los clientes.

*      Los métodos de cuenta que notifican los callbacks no deberán manipular el estado de las cuentas; la manipulación del saldo solo debe hacerse a través de los métodos apropiados ya presentes en la interfaz de cuenta.

*      Puede haber varios cajeros con callbacks fijados sobre un mismo objeto cuenta.

Los requisitos sobre la documentación, las simplificaciones y demás recomendaciones son similares a los de la práctica anterior. Cambia el modo de recoger las prácticas.

Requisitos sobre la entrega de la práctica:

*      Cada grupo deberá depositar los archivos de la práctica (sin comprimir) sobre un directorio denominado "SD2PC" que estará situado en su directorio de inicio en el host "duero.lab.fi.uva.es". Basta con que uno de los miembros del grupo deposite la práctica de esta forma.

*      En este directorio deberá haber un archivo denominado "componentes" con los nombres completos de los integrantes del grupo de prácticas. Sin perjuicio de que pueda aparecer su nombre en el resto de la documentación.

*      La práctica será recogida de forma automatizada por los técnicos del centro mediante un script que entrará en funcionamiento a las 0 horas del día 5 de Junio de 2004. Es decir, teneis de plazo para depositar la práctica hasta las once horas y 59 minutos de la noche del día 4 de Junio.