Usted está aquí: Inicio Ingeniería Informática Desarrollo de Aplicaciones Distribuidas Prácticas Implementación de un sistema de votación distribuido basado en Java RMI

Implementación de un sistema de votación distribuido basado en Java RMI

Acciones de Documento
  • Vista de contenidos
  • Marcadores (bookmarks)
  • Exportación de LTI
Autores: Alejandro Calderon Mateos, David Expósito Singh, Javier García Blas

Descripción

El objetivo de la práctica es la familiarización, por parte del alumno, con el uso de la API de Java RMI, así como con la arquitectura cliente/servidor. El alumno deberá diseñar, codificar y evaluar un sistema distribuido orientado al voto electrónico (descrito en la siguiente sección). El lenguaje empleado será el Java y el sistema operativo será el UNIX/Linux.

Objetivos

El objetivo del sistema es contabilizar los votos que se pueden realizar exclusivamente sobre dos candidatos llamados A y B. De este modo, un voto puede pertenecer únicamente a tres categorías: A, B o nulo.

Motivación

Existen dos factores que hay que considerar en el proceso de diseño: por una parte cada votante debe registrarse, para evitar que vote sucesivas veces. Por otra, es necesario almacenar los votos de forma anónima, respetando, de este modo, la privacidad y anonimato en el proceso de recuento electoral. En el ejercicio propuesto esto se logra mediante dos servidores, uno es responsable de registrar los votantes existentes (sin mantener el voto realizado) y otro realiza la función de urna electoral.

Estructura

El sistema distribuido consiste de tres aplicaciones:

  1. Un servidor Urna, que contiene exclusivamente el recuento de votos de cada una de las categorías.
  2. Un servidor Validación, que se encarga de recibir las peticiones de los clientes, registrarlos (para evitar que puedan votar varias veces) y emitir un voto en el servidor Urna.
  3. Varios Clientes, que se registran su voto en el servidor validación (junto con los datos personales del votante) y que pueden acceder al recuento (parcial) de votos ofrecido por el servidor Urna.


Figura Práctica 3

Desarrollo de la aplicación: 

El servidor Urna debe exportar un objeto remoto. Dicho objeto debe ofrecer dos métodos:

  • VOTO que recibe como argumento el tipo de voto realizado (A, B, BLANCO o NOVÁLIDO) y actualiza su categoría asociada.
  • RECUENTO que devuelve el número de votos de cada categoría

El servidor Validación debe exportar un objeto remoto con un único un método remoto:

  • PETICIÓN DE VOTO que recibe como argumento los datos del cliente (Nombre, ID y voto). Este método debe registrar al votante (para evitar que pueda realizar el voto varias veces) e invocar (en el caso de ser la primera vez que el votante se registra) el método VOTO del servidor Urna.



El Cliente únicamente debe acceder al método PETICIÓN DE VOTO del servidor Validación.

Mejoras

Una desventaja de la propuesta anterior es tanto el método VOTO como el RECUENTO son accesibles por el cliente. Una mejora consiste en hacer que sólo el método RECUENTO sea accesible por el cliente. De este modo, el servidor Urna debe exportar dos objetos diferentes, asociados a dos etiquetas (en el registro de objetos) distintas. Cada objeto tendrá uno de estos métodos, de modo que el objeto asociado al método VOTOserá únicamente accedido por el servidor de Validación mientras que el objeto asociado al método RECUENTO sólo será accedido por el cliente. NOTA: ambos objetos pueden estar en el mismo registro y no es necesario establecer técnicas que restrinjan el acceso al cliente. 

Por otro lado, con el fin de aumentar la robustez de la aplicación, es necesario tener en cuenta que el acceso al método VOTO puede fallar. De este modo, se propone la modificación de este método introduciendo:

  1. Una probabilidad de fallo P acotada en [0.0,1.0]. Se implementará mediante un generador de números aleatorios. En cada invocación del método, si P > 0.7 el voto se realizará y el método VOTO devuelve un valor 1. En caso contrario, se asume un error de acceso al servidor Urna. El método VOTO no actualizará su categoría asociada y devolverá el valor 0.
  2. En base al valor devuelto por VOTO, el servidor invocará un mecanismo de callback con el método ACK del cliente que realizó el voto, notificándole si ese voto se ha realizado de forma satisfactoria o si debe repetir el proceso. En este último caso, el cliente es borrado del registro y se debe repetir el proceso de votación.

Estructura del sistema de archivos para la entrega

Crear un directorio llamado DAD_PRAC1_2009 con tres subdirectorios llamados Serv1Serv2 y Cliente.

  • Serv1 corresponde al servidor Urna. Su código fuente debe estar dentro de este directorio. Su clase principal se denomina Servidor1 (debe aparecer en el fichero Servidor1.java). El argumento de entrada es el número de puerto en el que se inicia el registro RMI. El interface debe estar contenido en el fichero Serv1Interface.java y se debe denominar Serv1Interface. Su implementación debe estar en el fichero Serv1Impl.java y se debe denominar Serv1Impl.
  • Serv2 corresponde al servidor Validación. Su estructura es análoga a Serv1 (reemplazando Serv1 por Serv2). El argumento de entrada de la clase Servidor2 es la IP del servidor Urna, el puerto de su registro RMI y el puerto del registro RMI local.
  • La clase principal del cliente se denomina Cliente. Sus argumentos de entrada deben ser las IPs y puertos RMI de ambos servidores.

En el caso de añadir diferentes clases remotas se debe emplear el sufijo v2, v3, etc. Ej: Serv1v2Interface.java, Serv1v2Impl.java 

En el directorio DAD_PRAC1_2009 debe estar el fichero memoria.pdf con la memoria y documentación asociada a la práctica.

Reutilizar Curso
Descargar este curso