Primera práctica de la asignatura: Sistemas Distribuidos

Curso 2003-2004

 

Resumen

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.

 

Requisitos Generales:

*      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.

Requisitos:

*      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.

Requisitos sobre el diseño:

*      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.

Requisitos sobre la documentación:

*      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.

Requisitos sobre la entrega de la práctica:

*      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.

Simplificaciones y problemas que podemos encontrar en la resolución de la práctica:

*      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).

Recomendaciones para la confección de la práctica:

  1. En primer lugar podemos probar con una solución centralizada, y asumiendo un único usuario.
  2. Debemos tener en cuenta métodos “main” para implementar pruebas separadas por cada clase.
  3. Después podemos incorporar la gestión de secciones críticas que necesitemos para garantizar la atomicidad de la operación de transferencia bancaria.
  4. En este punto debemos de tener bien claro qué pruebas permiten garantizar que el sistema funciona adecuadamente, y con dos o más usuarios concurrentes.
  5. A continuación, implementaremos las partes correspondientes de RMI, pero con los procesos sobre la misma máquina para minimizar la influencia de los problemas de red sobre nuestra implementación.
  6. El último paso consiste en desplegar la aplicación sobre dos o tres máquinas diferentes para comprobar el buen funcionamiento.