Disseny d`aplicacions amb Objectes Distribuïts

Exercicis RMI.
Dels següents sistemes distribuïts feu:
• Anomeneu les diferents aplicacions que s’executaran, els diferens objectes
remots, les interfícies remotes que aprecieu en el sistema i els objectes
remots registrats al RMIRegistry amb la seva adreça URI.
• Feu el diagrama de classes complert de les diferents aplicacions que apareixen.
• Implementeu completament les diferents interfícies remotes que apereixin
en el sistema.
• Feu un exemple de cas d’ús anotant la seqüencia de crides a mètodes
remots que es farien en el sistema.
1
Lista de tareas colaborativa
Se desea diseñar e implementar un software que permita la gestión de una lista
de tareas común para un equipo de trabajo. Cada miembro del equipo trabaja
en un ordenador diferente y existe un ordenador que es el servidor de la empresa.
La aplicación debe mantener una lista de tareas para el equipo. De cada tarea se
guardará el nombre de la tarea, la persona del equipo a la que se le ha asignado
y si la tarea se ha realizado ya o no. Todos los miembros del equipo pueden
listar las tareas existentes, crear tareas nuevas , eliminar tareas (tanto las que
han creado ellos como las que han creado otros miembros del equipo) y marcar
tareas como realizadas. Para crear la tarea, se necesitará el nombre de la tarea,
la persona a la que se ha asignado y un identificador de tarea. Deberá tenerse en
cuenta si el identificador ya existe, ya que en ese caso no se podrá crear la tarea.
Para identificar una tarea que se desea eliminara o marcar como realizada, se
utiliza el identificador de la tarea. El director técnico de la empresa ha decidido
utilizar la tecnología RMI para resolver este problema.
2
Teletransporte
Se desea programar un sistema de teletransporte de mercancias entre los planetas del sistema solar. Todos los planetas están perfectamente conectados por
TCP/IP. Todos los planetas disponen de un único puerto de teletransporte. Se
ha desplegado un ordenador en cada planeta, para controlar su puerto de teletransporte. De cara a realizar un viaje, se necesita disponer de forma exclusiva
del puerto de teletransporte del planeta de origen y del puerto de teletransporte
del planeta de destino. Los viajes pueden iniciarse desde cualquier planeta con
destino a cualquier otro planeta. Es decir, en cada ordenador de control de
puerto de teletransporte existe una clase Java
1
p u b l i c c l a s s Enviador {
p u b l i c Enviador ( P l a n e t a o r i g e n ) ;
public void envia ( Planeta destino ) ;
}
que permite enviar aquello que se encuentre en la cabina de teletransporte
al planeta indicado siempre que se disponga de forma exclusiva de los puertos
de control de los planetas origen y destino durante el tiempo del envio. Ahora
mismo, lo que hacen es que cuando desde un planeta quieren enviar algo, llaman
por teléfono al planeta de destino antes de llamar al método envia, de forma
que se aseguran que nadie que no sea ellos van a utilizar el puerto del planeta
de destino. Después de haber realizado en envio, vuelven a llamar diciendo
que ya pueden recoger lo que han enviado y usar el puerto para otras cosas.
Últimamente han ocurrido algunos accidentes desagradables y la Federación
Galáctica está dispuesta a invertir para mejorar el sistema. Para funcionar
correctamente, se debe asegurar que nadie trabajará simultánteamente con los
puertos de los planetas que intervienen en esa operación de envío, mientras se
está efectuando la misma. Se quiere programar una nueva clase para distribuirla
a los ordenadores de todos los planetas:
p u b l i c c l a s s EnviadorSeguro {
p u b l i c EnviadorSeguro ( P l a n e t a o r i g e n ) ;
void envia ( Planeta destino ) ;
}
que se encargue de garantizar de forma automática (sin llamadas telefónicas)
el acceso en exclusiva a los puertos de teletransporte, de forma que disponiendo
de ella, el sistema sea más sencillo de programar. Para ello se utilizará la
tecnología de comunicaciones RMI. La Federación exige, obviamente, que el
sistema debe estar libre de deadlocks.
3
Gestió Notes
Se solicita implementar una aplicación RMI para gestionar las notas. La aplicación tiene definidas las clases: La aplicación tendrá dos tipos de usuario:
• El profesor introducirá las notas de una asignatura utilizando los métodos:
i n t r o d u c i r N o t a ( S t r i n g i d A s i g n a t u r a , S t r i n g idAlumno , S t r i n g nota )
b o r r a r N o t a ( S t r i n g i d A s i g n a t u r a , S t r i n g idAlumno , S t r i n g nota )
m o d i f i c a r N o t a ( S t r i n g i d A s i g n a t u r a , S t r i n g idAlumno , S t r i n g nota )
• El alumno dispone del método:
S t r i n g c o n s u l t a r N o t a ( S t r i n g i d A s i g n a t u r a , S t r i n g idAlumno )
2
4
Biblioteca
Se desea diseñar e implementar un software que permita la gestión del catálogo
de una biblioteca.
• El sistema se compone de:
– Un servidor central en el que se almacenan los datos de los libros.
– Un ordenador cliente para cada oficina, que se situará en la puerta
de la oficina.
– Un ordenador de gestión que se encuentra en el despacho del bibliotecario.
• Desde cada ordenador de consulta se podrá:
– Consultar la lista de autores de la que se dispone de algún libro.
– Buscar en el catálogo los libros de un determinado autor.
• Desde el ordenador de gestión, además se podrá:
– Añadir un nuevo libro al catálogo.
– Eliminar un libro del catálogo.
El diseño de la aplicación debe impedir que el ordenador de consulta realice las
operaciones de gestión. Se nos entregan, implementadas en Java y compiladas
(no disponemos del código fuente y por tanto no podemos hacer modificaciones)
las siguientes clases, cuyos métodos NO ofrecen garantías de ejecución utilizando
múltiples hilos:
public class Biblioteca {
public String [ ] obtenerAutores ( ) ;
/∗ Retorna una l i s t a que c o n t i e n e l o s l i b r o s de e s t e a u t o r .
Los o b j e t o s son l o s mismos o b j e t o s L i b r o guardados en l a
b i b l i o t e c a . No s e r e a l i z a una c o p i a de l o s o b j e t o s para
r e t o r n a r l o s . ∗/
public Libro [ ] buscarLibros ( String autor ) ;
/∗ Almacena un l i b r o en l a b i b l i o t e c a . El l i b r o no t i e n e
i d e n t i f i c a d o r al ser recibido , e l i d e n t i f i c a d o r se l e asigna
d e n t r o de e s t e método . S i todo ha i d o bien , r e t o r n a e l v a l o r
d e l i d e n t i f i c a d o r a s o c i a d o a l l i b r o . ∗/
p u b l i c i n t a ñ a d i r L i b r o ( L i b r o l ) throws L i b r o Y a E x i s t e ;
p u b l i c b o o l e a n e l i m i n a r L i b r o ( i n t i d ) throws L i b r o N o E x i s t e ;
}
public c l a s s Libro {
p u b l i c L i b r o ( S t r i n g autor , S t r i n g t i t u l o . S t r i n g e s t a n t e ) ;
p u b l i c S t r i n g getAutor ( ) ;
public String getTitulo ( ) ;
3
public String getEstante ( ) ;
public void s e t I d ( i n t id ) ;
public int getId ( ) ;
}
p u b l i c c l a s s LibroYaExiste extends Exception ;
p u b l i c c l a s s LibroNoExiste extends Exception ;
5
Subhasta Anglesa
El cap de tecnologia de l’empresa Automatismes Electrònics S.A us demana de
dissenyar i desenvolupar un software que gestioni la subhasta electrònica d’una
llotja de peix fresc de la comarca de l’Alt Empordà. El sistema es compon de:
• Un servidor central de la llotja amb la informació dels lots que es subhastaran aquella jornada
• Un comandament, tipus PDA, per cada client de la llotja que vulgui participar en la subhasta.
Aquests comandaments són wireless i implementen el protocol de comunicacions
TCP/IP. El sistema de subhastes funciona de la següent manera: Es tracta d’una
subhasta Anglesa (a l’alça), és a dir, per un lot determinat s’anuncia un preu
de sortida i l’hora en què s’acaba la subhasta. Els clients ha continuació han de
registrar-se a la subhasta i poden anar fent ofertes que superin el preu actual
del lot fins al final de subhasta d’aquell lot. El client que hagi dit l’oferta més
alta és qui el guanya. A continuació s’ofereix un altre lot, mentre en quedin per
subhastar. Les ofertes són públiques, tant el preu com qui l’ha dita. Ens donen,
ja implementades en JAVA i compilades (no disposem del codi font i per tant
no podem fer modificacions) les següents classes. Els mètodes d’aquestes classes
no ofereixen garanties d’execució fent servir múltiples fils.
p u b l i c c l a s s Lot {
p u b l i c Lot ( S t r i n g id , S t r i n g nom , S t r i n g p r e u I n i c i ,
Date f i S u b h a s t a ) ;
p u b l i c S t r i n g getNom ( ) ;
public String getPreuInici ( ) ;
p u b l i c S t r i n g f i S u b h a s t a ( ) ; /∗ HH:MM ∗/
public void s e t I d ( i n t id ) ;
public int getId ()
}
p u b l i c c l a s s CuaLot {
p u b l i c CuaLot ( ) ;
public afegirLotsDeFitxer ( ) ;
p u b l i c Lot s e g u e n t L o t ( ) ;
p u b l i c b o o l e a n quedenLots ( ) ;
}
4
6
Fusió de Caixes d’estalvis
La nova caixa d’estalvis sorgida de la fusió de les Caixes de Tàrrega, Seva,
Manresa i Gironella (Caixa Gitamasa) vol mantenir el seu sistema de banca
electrònica a cada una de les seves centrals, però necessita un sistema distribuït
de banca per tal que els antics usuaris puguin accedir als seus comptes des de
la nova Caixa Gitamasa independentment d’on es trobin les seves comptes.
Es demana dissenyar aquest sistema distribuït usant RMI que permeti:
• A un usuari de qualsevol entitat accedir a les seves comptes amb DNI i
password i poder consultar el seu estat, treure diners o fer un dipòsit.
• A un treballador de qualsevol entitat accedir a la informació de qualsevol
client (Nom, caixa a la que pertany, comptes..) de qualsevol entitat a
partir del seu DNI
• A un màxim responsable de cada entitat traspassar tots els clients i comptes
de la seva entitat al sistema distribuït de la nova caixa.
El sistema ha de ser el més modular possible per si es volen afegir noves funcionalitats.
7
Entregues de pràctiques.
El grup d’investigadors en Intel·ligència Artificial de la Facultat de Matemàtiques de la Universitat de Barcelona ha desenvolupat un sistema de correcció
de pràctiques automàtic, que en poca estona pot avaluar qualsevol pràctica
tenint en compte moltíssims factors. Un cop provat es vol posar en funcionament amb els alumnes del grau. Per això es vol crear un aplicatiu distribuït
que serveixi per a que els alumnes enviïn les seves pràctiques a un servidor, que
les avaluï i retorni la nota de la pràctica. Cal tenir en compte que l’avaluació
de la pràctica pot trigar estona, ja que ha de compilar, passar uns tests unitaris, buscar patrons en d’altres pràctiques per buscar còpies, etcètera... Per
tant l’alumne triarà si vol esperar-se ha saber la nota o en canvi desitja que
sigui notificat quan s’hagi calculat. Per altra banda, el professor podrà accedir
a l’aplicatiu per veure les notes de les entregues de pràctiques i, si eventualment
el procés ha fallat, posar la nota a mà.
Es demana dissenyar aquest sistema distribuït usant RMI que permeti:
• Alumne: Pujar una pràctica al servidor. L’alumne pot triar si vol esperarse a veure la nota i no fer res més, o en canvi continuar enviant altres
entregues i que sigui notificat quan les notes estiguin llestes.
• Alumne: Consultar notes d’entregues anteriors.
• Professor: Consultar notes d’entregues anteriors.
• Professor: Modificar notes d’entregues anteriors.
5
El sistema ha de ser el més modular possible per si es volen afegir noves funcionalitats.
8
Transferència de fitxers P2P
Es demana desenvolupar una aplicació peer2peer sobre RMI. Les funcionalitats
que es demanen són:
• Poder registrar-se en un servidor de peers. • Poder buscar entre tots els
peers connectats un arxiu pel seu nom.
• Poder descarregar-se un fitxer directament d’un peer.
• Poder desconnectar-se del servidor. Per cercar un arxiu el client (peer) fa
la petició al servidor.
El servidor pregunta aleshores a la resta de peers si disposen o no del fitxer i
respon al client amb la llista de peers que el tenen. La descàrrega es fa entre
peers, el servidor no té accés als fitxers. Per simplificar, la funció de descàrrega
rebrà com a paràmetre el nom del fitxer i un número de peça. Cada peça és
d’una mida fixa de bytes. S’ha de poder demanar al peer el nombre de peces
que conté un fitxer determinat. El sistema ha de ser el més modular i robust
possible. Cal preveure que un peer es pot quedar sense respondre.
9
Aplicació Distribuïda de Bicing
El responsable de tecnologia de l’Ajuntament de Palau-solità i Plegamans us
demana de dissenyar i desenvolupar un software distribuït que gestioni el servei
de lloguer de bicicletes del municipi, l’Ambicia’t. El sistema es compon de:
• Un servidor central
• Diverses estacions de bicicletes, 25 actualment però es preveu obrir-ne
més. Cada estació disposa d’una CPU i està connectada a la xarxa.
• Centenars de bicicletes. Incorporen una petita CPU, i connexió a Internet mitjançant wifi o GPRS, segons la cobertura. També disposa d’un
dispositiu GPS.
Els usuaris disposen d’una targeta que utilitzen per desancorar la bicicleta que
ells triïn de l’estació. Un cop l’hagin feta servir l’han de retornar a qualsevol
estació i deixar-la ben ancorada. Cada estació té un número variable, però fixat
de forats on ancorar les bicicletes. Cada estació ha de mantenir en tot moment
la informació sobre quants espais buits li queden i quines bicicletes té ancorades.
També es guardarà la informació sobre les bicicletes que han estat agafades de
l’estació i que de moment encara no han estat tornades a cap altra estació,
en concret interessa saber a quina hora ha estat agafada. Les accions que es
preveuen fer sobre les estacions inicialment són:
6
• Deixar Bicicleta.
• Agafar Bicicleta.
• Obtenir informació sobre quants espais buits queden.
• Avisar que una bicicleta d’aquesta estació ha estat retornada.
En Deixar Bicicleta, s’actualitza la informació sobre llocs buits i bicicletes ancorades. També es responsable d’avisar a l’estació d’origen que aquesta bicicleta
ha estat retornada.
En Agafar Bicicleta, s’actualitza la informació sobre llocs buits i bicicletes
ancorades. Així mateix s’incorpora aquesta bicicleta en la llista de bicicletes no
retornades encara.
Aquestes accions han de ser dutes de forma concurrent, ja que les estacions
poden gestionar moltes bicicletes alhora.
10
Estació Eòlica.
L’empresa d’Energies Renovables EcoLife té una estació eòlica que disposa de
100 aerogeneradors, cadascun d’ells disposa d’una cpu connectada a la seva
maquinària. Se’ns demana de fer un sistema distribuït per tal que els operadors
puguin obtenir el control en tot moment de qualsevol dels aerogeneradors.
Les operacions que han de poder controlar els operadors són:
• Obtenir la velocitat en que gira, la quantitat d’energia que està generant.
• Aturar/Engegar l’aerogenerador.
• Ajustar la potència del motor de rotació.
Tingueu en compte que poden haver-hi més d’un operador connectat a qualsevol
aerogenerador. El sistema ha de ser el més modular possible per si es volen afegir
noves funcionalitats.
11
Aplicació Distribuïda Hospital.
L’Hospital Clínic vol informatitzar cadascun dels llits dels pacients, de tal forma
que es quedin registrats totes les constants del pacient que les màquines que tingui connectades vagin recollint. Aquestes mesures han de poder ser consultades
pel metge que supervisa al pacient des de qualsevol lloc. També ha de poder
introduir valors com ara les dosis de medicaments o menjar que la màquina
del gota a gota va proporcionant al pacient. Es demana doncs fer un sistema
distribuït tal que quan un nou pacient ocupi un llit es registri en el sistema amb
el nom del client i el metge o metges que el supervisen. L’aplicatiu al qual te
accés el metge ha de ser capaç d’aconseguir el control del lloc on es trobi el seu
pacient, mitjançant el seu nom complet del pacient.
Les funcionalitats que vol fer anar el metge són:
7
• Obtenir el ritme cardíac, tensió arterial i temperatura, tant en el moment
actual com un històric des de que el pacient va entrar.
• Activar/Aturar la màquina del gota a gota, indicant el canal i poder ajustar la quantitat que es desitja subministrar en ml/h.
El sistema ha de ser el més modular possible per si es volen afegir noves funcionalitats.
12
Servei de xat.
Es demana desenvolupar un servei de xat sobre RMI. Les funcionalitats que es
demanen són:
• Poder registrar-se en un servidor de xat.
• Poder llistar i cercar usuaris que estiguin registrats en el servidor de xat.
• Poder acceptar o declinar l’inici d’una conversa de xat d’un usuari.
• Poder enviar un missatge de text a un usuari del xat.
• Poder deixar una conversa de xat.
• Poder deixar d’estar registrat en el servidor de xat.
El sistema ha de ser el més modular possible per si es volen afegir noves funcionalitats.
8
Exemple Diagrama de Classes
UnicastRemoteObject
HelloServer
HelloInterface
CallbackClient
Interface
sayHello( )
notifyMe( )
HelloImpl
C allbackC lie nt
UnicastRemoteObject
C allbackC lie nt
mpl
listRegistry( )
startRegistry( )
UML diagram
client
registry
server
rebind( )
lookup( )
sayHello( )
addCallback( )
notifyMe( )
sequence diagram
Figure 1: UML Diargama de classesd’exemple
9