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