CAPITULO
RM I avanzado
En el últim o capítulo, Java RMI se describió com o ejem plo de un
sistem a de objetos d istribuidos. En dich o capítulo sólo se
m ostraron las características de diseño más básicas de RMI,
aunque se m encionó que el API poseía un extenso conjunto de
características. El lector puede ignorar este capítulo si no está
interesado en explorar de form a más detallada RMI. Sin em bargo,
es m uy recom endable el uso de los gestores de seguridad (véase
El g e sto r de seguridad de RMI) en todas las aplicaciones RMI.
Este capítulo analizará algunas de las características avanzadas
de RMI más interesantes, a saber, descarga de resguardo,
gestores de seguridad, y ca llb a ck de cliente. A unque no se trata
de características inherentes del paradigm a de objetos distribuidos,
se trata de mecanism os que pueden ser útiles para los
desarrolladores de aplicaciones. A dicionalm ente, el e studio de
estos tem as perm ite al lector reforzar su conocim iento del
paradigm a de objetos d istribuidos en general, y del API de RMI en
particular.
8 .1 . C A LLB A C K D E C L IE N T E
Considérese una aplicación RMI donde un servidor de objeto debe notificar a los pro
cesos participantes la ocurrencia de algún evento. Como ejemplos, en un chai, cuan
do un nuevo participante entra, se avisa al resto de los participantes de este hecho;
[Link]
en un sistema de subastas en tiempo real, cuando empiezan las ofertas, se debe avi
sar a los procesos participantes. Esta característica tam bién es útil en un juego en red
cuando se informa a los jugadores de la actualización del estado del juego. Dentro del
entorno del API básica de RMI presentada en el capítulo anterior, es imposible que
220 C om putación distribuida. Fundam entos y aplicaciones
el servidor inicie una llamada al cliente para transmitirle alguna clase de información
que esté disponible, debido a que una llamada a método remoto es unidireccional (del
cliente al servidor). Una forma de llevar a cabo la transmisión de información es que
cada proceso cliente realice un sondeo a l servidor de objeto, invocando de forma re
petida un método remoto, que supóngase que se llam a haComenzado Oferta, hasta que
el método devuelva el valor booleano verdadero:
In te rfa z S e rv id o r h =
( I n t e r f a z S e r v i d o r ) N a m i n g .l o o k u p ( U R I R e g i s t r o ) ;
w h i l e ( ! ( h . h a C a n e n z a d o O f e r ta ( ) ) {; >
/ / c o m ie n z a l a o f e r t a
El sondeo {paB htg es de hecho una técnica empleada en muchos programas de
red. Pero se trata de una técnica m uy costosa en términos de recursos del sistema, ya
que cada invocación de un método remoto implica un hilo separado en la máquina
servidora, además de los recursos de sistema que su ejecución conlleva. Una técnica
más eficiente se denomina ca flh a rk. permite que cada cliente de objeto interesado en
la ocurrencia de un evento se registre a sí mismo con e l servidor d e objeto, de for
ma que el servidor inicie una invocación de un método remoto del cliente d e objeto
cuando dicho evento ocurra. La Figura 8.1 compara las dos técnicas: sondeo y call-
back.
Sondeo C a llb a c k
Un d ie n te realiza una U n cliente se registra en
petición al servidor el servidor y espera a que
repetidam ente hasta que el servidor realice un callback.
obtiene la respuesta deseada.
Llamada a m étodo rem oto
F ig u ra 8 .1 . Sondeo (polling) frente a callback.
En RMI, el caBbadt de diente es una característica que permite a un cliente de
objeto registrarse a sí mismo con un servidor de objeto remoto para caBbads, de for
ma que el servidor pueda llevar a cabo una invocación del método del cliente cuan
do e l evento ocurra. H ay que observar que con los callbacks de clientes, las invoca
ciones de los métodos remotos se convierten en bidireccionales, o dúplex, desde el
[Link]
cliente al servidor y viceversa. Debido a que el API de RMI básica, introducida en el
capítulo anterior, sólo permite la invocación de métodos remotos de clientes en ser
vidores de objetos, se necesita claramente sintaxis adicional para dar soporte a esta
nueva característica.
RMI avanzado 221
Cuando un servidor de objeto realiza un callback, los papeles de los dos procesos
se invierten: el servidor de objeto se convierte en cliente del cliente de objeto, debi
do a que el primero inicia una invocación de método remoto en el segundo.
La Figura 8.2 muestra la arquitectura de RMI con callback de cliente. Compara
da con la arquitectura básica de RMI, se puede observar que en este caso se necesi
tan dos conjuntos de proxies, uno para la interfaz remota del servidor, como en la ar
quitectura básica de RMI, y otro para una interfaz adicional, la interfaz remota del
cliente. La interfaz remota del cliente proporciona un método remoto que puede in
vocar el servidor a través del callback.
......................El cliente busca el objeto rem oto
► El cliente invoca el m étodo rem oto del servidor
El servidor invoca el m étod o de callbackdel cliente
F ig u ra 8 2 . La a rq u ite c tu ra d e R M I c o n ca llb a c k d e clie n te .
Como ejemplo, se extenderá la aplicación HolaMundo, presentada en el capítulo
anterior, de forma que e l cliente del objeto se registre con el servidor para callback
y entonces se le notifique cualquier registro de otro cliente de objeto para callback
con el servidor.
Extensión de la parte cliente para ca llb a c k de cliente
Para el callback, el cliente debe proporcionar un método remoto que permita al ser
vidor notificarle el evento correspondiente. Esto puede hacerse de una forma similar
a los métodos remotos del servidor de objeto. En la siguiente subsección se describe
la sintaxis necesaria para llevar a cabo esto.
[Link]
La interfaz rem ota de cliente
Es importante recordar que el servidor de objeto proporciona una interfaz rem ota que
declara los métodos que un cliente de objeto puede invocar. Para el callback, es ne