Implementación de un sencillo ejemplo de operación sobre objetos remotos. La interfaz de usuario de la aplicación permitirá ingresar, retirar y consultar el saldo de cuentas bancarias implementadas como objetos remotos. Además se permitirá realizar una operación de transferencia de fondos de una cuenta bancaria a otra.
La interfaz de la aplicación será, preferentemente textual, y ofrecerá la posibilidad de consultar el saldo, ingresar y retirar fondos de cuentas bancarias.
El saldo de las cuentas bancarias será una cantidad entera de céntimos de euro.
El usuario identifica cada cuenta bancaria por un nombre en forma textual.
La interfaz de la aplicación podrá efectuar transferencias de fondos de una cuenta bancaria a otra (en una sola operación), bajo la condición de que existan fondos suficientes para cubrir la transferencia.
El sistema confirmará al usuario la realización de cada operación de ingreso o extracción frente a posibles fallos.
Cada usuario sólo podrá realizar sus operaciones en formato serie: no se permitirá ejecutar dos operaciones simultáneamente.
Cada operación de ingreso, extracción o transferencia de un usuario podrá ocurrir concurrentemente con otras operaciones de otros usuarios.
La transferencia de fondos deberá realizarse de
forma atómica y ser fiable frente a fallos.
Atómica, significa que se realizará
como una sola operación o, si no es posible por que las condiciones no fueran
adecuadas, fallará dejando el sistema en el mismo estado en que se encontraba
anteriormente.
Las cuentas bancarias se implementarán mediante objetos “Cuenta” y se comunicarán mediante Java RMI.
La interfaz de la aplicación de usuario actuará de frontal frente a un objeto de la clase “Cajero”, que realizará las operaciones remotas correspondientes en representación del usuario.
Los objetos referentes a las cuentas bancarias de una transferencia podrán residir en máquinas bancarias diferentes.
El Cajero podrá residir en una máquina diferente a la de los objetos Cuenta.
Los programas deberán ir convenientemente documentados mediante la herramienta JavaDoc.
Se acompañará a la aplicación de un informe de despliegue y de las pruebas realizadas en formato html.
La práctica se entregará como máximo hasta el viernes 30 de abril a las 13:30, por correo electrónico, y comprobando con el profesor la recepción correcta de dicho correo.
El problema de los nombres simbólicos para cada cuenta puede obviarse, no siendo necesario mantener un directorio, ni autenticar los usuarios frente al sistema.
La interfaz de usuario podrá ser, en primera aproximación, rudimentaria y basada en mandatos de línea de texto, de modo que podemos diseñar una interfaz que suponga un usuario bien comportado (el/la diseñador/a).
Los problemas vienen por el frente de la conexión de objetos remotos,
Y también por el requisito de atomicidad de la operación de transferencia, donde debemos comprobar los saldos, y establecer condiciones de sincronización sobre métodos o incluso clases enteras.
Aun así, la atomicidad de la operación puede romperse debido a algún tipo de fallo al invocar los métodos aisladamente, por lo que debemos diseñar la “Transacción” de modo que sea resistente frente al catálogo de posibilidades de fallo que se pueden dar en la operación real.
El diseño final no tiene porqué ser perfecto al ciento por ciento. De hecho no existe ninguna solución cien por cien realista que no pase por construir un sistema realmente complicado (aun para una sencilla transacción), y la presencia de un operador humano (en último término).