3.9 Patrón Distributed callback

Transcripción

1 3.9 Patrón Distributed callback

2 Motivación (1) Queremos que la aplicación de administración de los termostatos Monitorize la temperatura de algunos termostatos, avisándonos si ésta baja o sube por encima de un determinado umbral Monitorize las altas y bajas de termostatos en determinadas habitaciones (consecuencia de otros administradores usando la herramienta concurrentemente) Posible solución: polling La herramienta de administración dispone de tres threads Thread-1: ejecuta el interfaz de usuario Thread-2: invoca periódicamente a Thermostat::getState sobre los termostatos que desea monitorizar el usuario, y actualiza estructuras internas y refresca el interfaz de usuario si ha notado cambios Thread-3: idem con Controller::findByLocation sobre las habitaciones de interés

3 Motivación (y 2) Problemas con el polling Puede saturar al servidor Ej.: varios usuarios usando la herramienta de administración y un servidor que maneje cada petición en un thread Puede congestionar la red Posible solución => Distributed callback Es una aplicación del patrón Observer Veremos Qué es lo que cambia en un entorno distribuido y con CORBA? Qué problemas adicionales puede tener en un entorno distribuido?

4 Ejemplo tcsdc Es tcsfactory modificado para monitorizar altas y bajas de termostatos La aplicación de administración dispone de un objeto CORBA, ThermostatObserver, que registra en el Controller, de manera que cada vez que hay una alta o baja de un termostato, el servidor invoca una operación sobre ThermostatObserver para notificar el cambio El servidor tiene una referencia a un ThermostatObserver por cada aplicación de administración Cuando la aplicación de administración termina, de-registra su ThermostatObserver del Controller La aplicación de administración dispone de dos threads Thread-1: ejecuta el interfaz de usuario Thread-2: (main): ejecuta ORB.run

5 Primer enfoque: es::udc::fbellas::corba::tcsdc::idl (1) struct LifeCycleEvent { string fthermostatidentifier; boolean fcreated; }; interface ThermostatObserver { void notifylifecycleevent(in LifeCycleEvent event); }; interface Controller { void addthermostatobserver(in ThermostatObserver observer); void removethermostatobserver(in ThermostatObserver observer); }; // Resto de operaciones...

6 Primer enfoque: es::udc::fbellas::corba::tcsdc::idl (y 2) La notificaciones llevan el evento Evita que el cliente tenga que pedirlo (ahorra invocaciones remotas) Además, el pedirlo podría ser un problema con POAs uni-thread en la aplicación de administración y en el servidor Los objetos callback (ej.: ThermostatObserver) normalmente son transient Sólo existen durante el tiempo de vida de una ejecución de la aplicación observadora Ilustra una característica muy frecuente en las aplicaciones que usan objetos distribuidos => suelen actuar como clientes y servidores Sistemas peer-to-peer y no cliente-servidor puro Problema El servidor tendría que implementar Controller::removeThermostatObserver eliminado de su lista de observadores la referencia que recibe como parámetro, pero en CORBA, las referencias no se pueden comparar

7 Segundo enfoque: es::udc::fbellas::corba::tcsdc::idl struct LifeCycleEvent { string fthermostatidentifier; boolean fcreated; }; interface ThermostatObserver { void notifylifecycleevent(in LifeCycleEvent event); }; interface Controller { long addthermostatobserver(in ThermostatObserver observer); void removethermostatobserver(in long observeridentifier); }; // Resto de operaciones... Problema de seguridad Cualquier aplicación puede cancelar objetos ThermostatObserver de otras aplicaciones

8 La solución: es::udc::fbellas::corba::tcsdc::idl (1) struct LifeCycleEvent { string fthermostatidentifier; boolean fcreated; }; interface ThermostatObserver { void notifylifecycleevent(in LifeCycleEvent event); }; interface Controller { ThermostatObserverTerminator addthermostatobserver( in ThermostatObserver observer); // Resto de operaciones... }; interface ThermostatObserverTerminator { void terminate(); };

9 La solución: es::udc::fbellas::corba::tcsdc::idl (y 2) Comentarios Controller::addTermostatObserver es una operación factoría que crea un ThermostatObserverTerminator por cada observador Cuando la aplicación de administración quiere de-registrar su objeto observador usa la referencia ThermostatObserverTerminator que obtuvo anteriormente, invocando terminate sobre ella ThermostatObserverTerminator normalmente es un objeto transient El servant de ThermostatObserverTerminator tiene que disponer de un atributo que identifique de forma única al observador al que hace referencia, para poder eliminarlo de la lista de observadores a notificar

10 Estructura de paquetes de tcsdc Idem tcsfactory más es::udc::fbellas::corba::tcsdc:callbacks Implementa el interfaz remoto ThermostatObserver Principales cambios con respecto a tcsfactory Servidor es::udc::fbellas::corba::tcsdc::idl es::udc::fbellas::corba::tcsdc::server::wrapper s Aplicación de administración es::udc::fbellas::corba::tcsdc::callbacks Dos threads: uno para el interfaz de usuario y otro (main) para escuchar las notificaciones (ORB.run)

11 es::udc::fbellas:corba::tcsdc::server::wrappers ThermostatObserverTerminatorPOA - observeridentifier : int ThermostatObserverTerminatorImpl <<create>> + ThermostatObserverTerminatorPOAImpl(observerIdentifier : long) ControllerImpl <<use>> <<use>> - observers : java::util::map - nextobserveridentifier : int ThermostatEventNotifier + addthermostatobserver(observer : es::udc::fbellas::corba::tcsdc::idl::thermostatobserver) : int + removethermostatobserver(observeridentifier : int) : void + notifylifecycleevent(event : es::udc::fbellas::corba::tcsdc::idl::lifecycleevent) : void 0..n <<IDL interface>> ThermostatObserver (from idl)

12 es::udc::fbellas:corba::tcsdc::server::wrappers::thermostateventnotifier (1) final class ThermostatEventNotifier { private static Map observers = new HashMap(); private static int nextidentifier = 0; private ThermostatEventNotifier() {} static synchronized int addthermostatobserver( ThermostatObserver observer) { observers.put(new Integer(nextIdentifier), observer); return nextidentifier++; } static synchronized void removethermostatobserver( int observeridentifier) { observers.remove(new Integer(observerIdentifier)); }

13 es::udc::fbellas:corba::tcsdc::server::wrappers::thermostateventnotifier (y 2) static synchronized void notifylifecycleevent(lifecycleevent event) { Iterator observeriterator = observers.values().iterator(); while (observeriterator.hasnext()) { try { ThermostatObserver observer = (ThermostatObserver)observerIterator.next(); observer.notifylifecycleevent(event); } catch (SystemException e) { /* * We suppose that the corresponding client finished * without unregistering its observer. */ observeriterator.remove(); } } } }

14 es::udc::fbellas:corba::tcsdc::server::wrappers::thermostatobserverterminatorimpl (1) class ThermostatObserverTerminatorImpl extends ThermostatObserverTerminatorPOA { private int observeridentifier; ThermostatObserverTerminatorImpl(int observeridentifier) { this.observeridentifier = observeridentifier; } public void terminate() { /* Remove observer reference. */ ThermostatEventNotifier.removeThermostatObserver( observeridentifier); /* Deactivate this object from the active object map. */ try { byte[] objectidentifier = _default_poa().servant_to_id(this); _default_poa().deactivate_object objectidentifier)); } catch (Exception e) { /* Ignore. */ } } } // class

15 es::udc::fbellas:corba::tcsdc::server::wrappers::thermostatobserverterminatorimpl (y 2) Para desactivar el objeto necesitamos conocer su identificador Dado que lo hemos creado con el Root POA (SYSTEM_ID), no lo conocemos Podemos averiguarlo con org::omg::portableserver::servant::_object_i d (visto con el patrón Default Servant ) o con PortableServer::POA::servant_to_id (el que usa el ejemplo) PortableServer::POA::servant_to_id requiere un POA con política RETAIN

16 es::udc::fbellas:corba::tcsdc::callbacks ThermostatObserverPOA - observer : ThermostatObserver ThermostatObserverImpl + ThermostatObserverImpl() + setthermostatobserver(observer : ThermostatObserver) : void 1 <<Interface>> ThermostatObserver + notifylifecycleevent(event : LifeCycleEvenrt) : void - thermostatidentifier : String - created : boolean LifeCycleEvent LifeCycleEvent(thermostatIdentifier : String, created : boolean) + getthermostatidentifier() : String + iscreated() : boolean

17 es::udc::fbellas:corba::tcsdc::callbacks::thermostatobserverimpl public class ThermostatObserverImpl extends ThermostatObserverPOA { private ThermostatObserver observer; public ThermostatObserverImpl() {} public void setthermostatobserver(thermostatobserver observer) { this.observer = observer; } public void notifylifecycleevent( es.udc.fbellas.corba.tcsdc.idl.lifecycleevent event) { observer.notifylifecycleevent(fromidl(event)); } private LifeCycleEvent fromidl( es.udc.fbellas.corba.tcsdc.idl.lifecycleevent event) { return new LifeCycleEvent(event.fThermostatIdentifier, event.fcreated); } } // class

18 Características no ilustradas por el ejemplo Filtrado Cuando se registra un observador se asocia una condición (objeto local, un struct en IDL) que ha de cumplirse para que el evento sea de interés para el observador Ej.: ObserverTerminator addobserver(in Observer anobserver, in Condition acondition) Los objetos observadores suelen ser a su vez notificadores de observadores locales Ej.: propagar eventos a distintas partes del interfaz de usuario

19 Problemas (1) Persistencia de la lista de referencias a observadores Para que la posible caída de un servidor sea transparente a las aplicaciones observadores, éste debería guardar las referencias en disco Se produce SystemException al invocar una operación sobre un observador Dado que los objetos callback normalmente son transient Si la excepción es TRANSIENT con estado de completitud COMPLETED_NO, se pueden hacer n reintentos, y eliminar el objeto callback si fallan todos También se podría implementar un mecanismo de keepalive Los observadores envían un mensaje de keep-alive (invocan una operación) al notificador cada cierto tiempo El notificador tiene un thread que despierta periódicamente y elimina los observadores que no hayan enviado el mensaje de keep-alive durante el último periodo

20 Problemas (2) Escalabilidad La solución mostrada en el ejemplo no es escalable Ej.: considerar la situación de un gran número de observadores, que además han asociado condiciones al registrarse Para conseguir escalabilidad necesitamos necesariamente federar Jerarquía de notificadores Observadores

21 Problemas (y 3) Fuerte acoplamiento entre observadores y notificadores En el ejemplo tcsdc se ha necesitado Modificar el interfaz Controller (para añadir la operación de registro) Crear el interfaz ThermostatObserverTerminator Crear el interfaz ThermostatObserver Los observadores conocen a los notificadores Si un observador quiere recibir adicionalmente eventos de otro notificador, necesita registrarse en él => modificar el código Observadores maliciosos o colgados El thread que invoca la operación de notificación en el servidor puede quedarse colgado si el observador no termina nunca la operación A veces se usa oneway, pero no es buena solución (ahora existe una solución más potente: Messaging )

22 Servicio de eventos y notificaciones Servicio de eventos Ofrece canales de eventos Un canal puede tener múltiples publicadores y observadores Los eventos son de tipo any Publicadores y subscriptores no se conocen Soporta federación Limitaciones No permite especificar nivel de calidad de servicio Ej.: qué ocurre si un publicador envía tantos eventos que el canal correspondiente no es capaz de entregarlos a los observadores? No soporta filtrado Ej.: El administrador de la aplicación de termostatos quiere que se le notifique sólo cuando la temperatura de Thermostat-1 y Thermostat-4 suba por encima de 26 grados Si el filtrado lo implementa la aplicación de administración, el servidor haría más trabajo del necesario y la red podría congestionarse Servicio de notificaciones Añade más interfaces al servicio de eventos (compatible con él) y hace frente a sus limitaciones

23 Conclusiones Cuándo usar el patrón Distributed callback? En situaciones sencillas y que no requieren escalabilidad Cuándo usar el servicio de eventos? Situaciones más complejas, con requisitos de escalabilidad, pero no de filtrado y/o calidad de servicio Cuándo usar el servicio de notificaciones? Situaciones más complejas, con requisitos de escalabilidad, filtrado y calidad de servicio

24 Ejecución de tcsdc * cd $CORBA_JAVA_EXAMPLES_HOME/Subsystems/ORB/Scripts/NamingService * Ejecutar NamingService.sh (debe existir el contexto es/udc/fbellas/corba/tcsdc ) * cd $CORBA_JAVA_EXAMPLES_HOME/Subsystems/TCSDC/Scripts (En este directorio se encuentran ubicados los subdirectorios Acme1Thermostats y Acme2Thermostats, que contienen los ficheros que simulan los termostatos). * Ejecutar TCSDCServer.sh * Ejecutar TCSDCAdmin.sh * Ejecutar otro TCSDCAdmin.sh