Framework para la ayuda en el desarrollo de aplicaciones sensibles al contexto. Autor: Carlos Rodríguez Domínguez

Transcripción

1 Framework para la ayuda en el desarrollo de aplicaciones sensibles al contexto Autor: Carlos Rodríguez Domínguez

2 Que es una aplicación distribuida? Es una aplicación cuyos componentes se ejecutan en entornos separados, normalmente distintas plataformas conectadas a través de una red. Los componentes que conforman una aplicación distribuida son: cliente, servidor, protocolo de intercambio de información y formato de los mensajes intercambiados.

3 Que es una aplicación sensible al contexto? Las aplicaciones sensibles al contexto son aquellas que adaptan su comportamiento según la información recibida del entorno físico y del propio entorno computacional. Por su propia filosofía, son aplicaciones distribuidas. En el desarrollo de aplicaciones sensibles al contexto se requiere un gran esfuerzo para poder coordinar, comunicar e integrar los diversos dispositivos que forman el sistema: A menudo tendremos lenguajes de programación distintos, en máquinas distintas, con distintas capacidades, etc.

4 Aportaciones del framework a la computación sensible al contexto Comunica entidades mediante eventos. Permite acceder a metainformación del propio sistema. Se implementan mecanismos de seguridad, como el hecho de que todas las comunicaciones se realicen sobre SSL.

5 Desarrollo del Framework (I) Un Framework para el desarrollo de aplicaciones sensibles al contexto deberá dar soporte a dos aspectos fundamentales: Acceso a información descriptiva acerca de estas aplicaciones (metainformación) y un mecanismo de distribución de información asíncrona (eventos), para poder comunicar los distintos dispositivos y aplicaciones. El framework debe ser sumamente portable: Se utilizara en dispositivos con distintos procesadores, SO s, lenguajes de programación, etc.

6 Desarrollo del Framework (II) Por la propia filosofía de los sistemas sensibles al contexto (y los distribuidos en general), la arquitectura idónea para el framework deberá estar basadas en servicios. Se definirá un servicio para cada aspecto (metainformación y eventos) del framework. De parte del cliente, se definirá una interfaz, lo mas simple y abstracta posible para el acceso a estos servicios.

7 Desarrollo del Framework (III) Para la transmisión de datos, conviene usar protocolos ampliamente usados actualmente y que nos permitan comunicar plataformas hardware y software heterogéneas. Se hará uso de las especificaciones CORBA como base del framework. CORBA nos proveerá también de un servicio de nombres y de un servicio de distribución de eventos. Además nos asegura la compatibilidad entre los datos recibidos y los emitidos.

8 Desarrollo del Framework (IV) Sobre la base de CORBA se deberá definir lo siguiente: el servicio de metainformación y una definición genérica de la estructura de los eventos, así como un sistema simple para su envío y recepción. La idea es que el uso del framework implique únicamente un mínimo de conocimientos en sistemas de éste tipo y ningún tipo de conocimientos acerca de CORBA. También hay que asegurar que el framework pueda trabajar en cualquier dispositivo digital (ubicuidad).

9 Servicio de metainformación (I) Este servicio posee capacidades para la gestión de aplicaciones, usuarios, roles y componentes (elementos susceptibles de tener un permiso de uso para un usuario y un rol). El servicio también tiene la capacidad de almacenar su estado de forma persistente y recuperarlo. Cualquier cambio en el estado del servicio será propagado a los clientes para evitar inconsistencias.

10 Servicio de metainformación (II) El servicio es el encargado de mantener toda la información. Los clientes solo acceden para leer y escribir esta información de forma puntual. En ningún caso se obligará a los clientes (aunque será posible) a mantener toda la metainformación del sistema de forma local (sería muy costoso para ellos). El servicio actua como una pizarra en la que leer y escribir información. De esta forma aseguraremos que la información que se lea o se escriba en un momento dado siempre será consistente.

11 Servicio de metainformación (III) El servicio mantiene la siguiente información: Una aplicación estará compuesta por usuarios, roles y componentes. Cada usuario tendrá un nombre de usuario y un password. Cada usuario tendrá un conjunto de roles posibles en el sistema. También tendrá un rol predeterminado. Cada usuario, con un rol específico, tendrá permisos para acceder (o no) a ciertas partes del sistema.

12 Servicio de metainformación (IV) Para almacenar persistentemente la información anterior y recuperarla, se hace uso de una base de datos. Gracias al uso de una base de datos, la información no tendrá por qué estar almacenada localmente en la máquina que ejecute el servicio de metainformación.

13 Servicio de metainformación (V) De parte del cliente se ha creado una interfaz que facilita el acceso y uso del servicio. Ésta interfaz también se encarga de transmitir eventos que indican el cambio en la información almacenada en el servicio cuando se escriben nuevos datos en éste. De ésta forma, si, por ejemplo, tenemos una aplicación con una lista que muestra los usuarios conectados y un cliente nuevo se conecta, se transmite un evento para indicar que esa lista debería ser actualizada (los eventos y la forma de capturarlos se explicará en profundidad a continuación).

14 Servicio de metainformación (VI) Se puede observar como el servicio de metainformación no envía eventos. De ésta forma queda desacoplado del servicio de eventos. Cliente Eventos E/S metainformación Cliente Servicio de metainformación E/S persistente Eventos Eventos BD Cliente

15 Servicio de eventos (I) El servicio de eventos se encarga de distribuir eventos a todos los clientes y de consumir los eventos distribuidos. Consumidor Emisor push() push() EventService push() Consumidor Emisor push() push() push() Consumidor Consumidor

16 Servicio de eventos (II) Se ha creado una interfaz de acceso a EventService que abstrae sobre el hecho de ser un emisor o un consumidor: Todo cliente será emisor y consumidor a la vez. Esta interfaz se llama EventHandler. Para el envío de eventos, se provee del método push(). Para recibir los eventos, se mezclan dos artificios: Listeners y ListeningObjects.

17 Servicio de eventos (III) Un listener será una interfaz de la cuál tendremos que implementar los siguientes métodos: EventListener +check(data:genericobject) : boolean +action(receiver, data:event) : void +name() : string check(data:genericobject) : boolean Comprobar si un objeto genérico se corresponde con alguno de los eventos a capturar por el listener action(receiver, data:event) : void Acción que se ejecutará si el evento puede ser capturado por este listener (se comprobará con el método anterior). name() : string Nombre único para el listener. Entre otras cosas, puede servir para comparar si dos listeners son iguales.

18 Servicio de eventos (IV) Un ListeningObject es un objeto genérico que acepta listeners. Cada objeto tendrá un número indefinido de listeners y podremos asociarles nuevos listeners o eliminarlos en tiempo de ejecución. Cada ListeningObject deberá registrarse en el EventHandler. A partir de ese instante, si se recibe un evento adecuado para alguno de los listeners, se ejecutará la acción asociada. Los ListeningObjects pueden ser registrados y desregistrados en tiempo de ejecución.

19 Servicio de eventos (V) Resta por definir que es un evento. El problema inicial era como definir un evento lo suficientemente genérico para cualquier problema. La solución fue la implementación de los eventos como una estructura dinámica. De manera abstracta, un evento funciona como un struct de C/C++, solo que en tiempo de ejecución podremos asociarle tantos campos como deseemos, con el nombre y tipo que deseemos. Por defecto todos tendrán un campo llamado type, que será un valor único para cada evento.

20 Servicio de eventos (VI) Tendremos los siguientes métodos básicos para los eventos: exists_member(name:string) : boolean Comprobar si el evento tiene un campo determinado member_value(name:string) : GenericObject Obtiene el valor de un campo o un objeto genérico nulo si no existe member_value(name:string, data:genericobject) : void Asigna el valor de un campo. Si el campo no existe, lo crea to_any(data:genericobject) : void Convierte el evento a un objeto genérico. from_any(data:genericobject) : void Convierte un objeto genérico en un evento

21 Servicio de eventos (VII) La clase GenericObject es un Wrapper para cualquier tipo susceptible de ser enviado o recibido a través de los diversos servicios implementados en el framework. Pueden ser los tipos primitivos portables entre lenguajes y máquinas (Integer, Long, Float y Double), también las cadenas de texto, los propios eventos, listas de usuarios, de roles, de aplicaciones, etc. También acepta cualquier tipo de los soportados por CORBA. Gracias a ésta clase, la versatilidad de los eventos es muy amplia, ya que podrán ser adecuados a las necesidades propias de cada problema.

22 Servicio de eventos (VIII) Las posibles subclases de la clase Event tendrán por único objetivo el acceso más cómodo a los diversos campos. El acceso a éstos campos siempre será posible desde la superclase. Por defecto, el framework implementa eventos para parejas de datos, dibujos (lineas, círculos, triángulos, etc.) y metainformación.

23 Diagrama UML del servicio de eventos Event - event:eventnode[n] - create_member(name:string, value:genericobject) : void +exists_member(name:string) : boolean +member_value(name:string, exists:boolean) : GenericObject +member_value(name:string) : GenericObject +member_value(name:string, value:genericobject) : void +member_value(name:string, value:integer) : void +member_value(name:string, value:long) : void +member_value(name:string, value:float) : void +member_value(name:string, value:double) : void +member_value(name:string, value:string) : void +count_members() : Integer +is_compatible(data:genericobject) : boolean +to_any(data:genericobject) : void +from_any(data:genericobject) : void Eventos para cuestiones especificas (metainformacion, controladores de vistas, etc.) Events * tiene_secuencia emite_recibe EventHandler -objects:listeningobject[num_objects] -channel_out:eventhandlersupplier -channel_input:eventhandlerconsumer +push(ev:event) : void +register_object(obj:listeningobject) : void +unregister_object(obj:listeningobject) : void 0..* 1 maneja * EventNode +name:string +value:genericobject usa_consumidor_eventos 1 EventSupplier -orb:corba::orb -channel:corba::eventchannel -supplier_admin:corba::supplieradmin -proxy_consumer:corba::proxyconsumer +push(data:genericobject) : void +disconnect_push_supplier() : void usa_emisor_eventos 1 EventHandlerSupplier Objetos que acepten listeners especificos (botones, pulsadores, listas, motores, ventanas, etc.) Objects 0..* ListeningObject -listeners:eventlistener[num_listeners] +addeventlistener(ev:eventlistener) : void +removeeventlistener(ev:eventlistener) : void +removeeventlistener(name:string) : void +listen(data:genericobject) : void 1..* tiene_asociado 1..* 1..* EventListener +check(data:genericobject) : boolean +action(receiver, data:event) : void +name() : string 1 EventHandlerConsumer EventConsumer -orb:corba::orb -channel:corba::eventchannel -consumer_admin:corba::consumeradmin -proxy_supplier:corba::proxysupplier +push(data:genericobject) : void +disconnect_push_consumer() : void hacen_uso 0..* Listeners Listeners para cuestiones especificas (metainformacion, controladores de vistas, etc.)

24 Diagrama de despliegue El siguiente diagrama nos muestra la distribución de los componentes del framework en las diversas máquinas que conforman un sistema distribuido Servidor CORBA Servidor Almacenamiento NameService DataBase MIService DataAccessor EventService Cliente MIServiceConnector EventHandler ListeningObject

25 Conclusiones El framework ahorra una gran cantidad de esfuerzo en la implementación de aplicaciones sensibles al contexto, con lo que es de un enorme interés. El uso de recursos por parte del framework es mínimo. El framework no está sujeto al uso de un determinado lenguaje de programación o a la emisión de eventos por parte solo de GUI s. Cualquier dispositivo o aplicación puede recibir/emitir eventos.

26 Conclusiones Es un gran paso para permitir que los desarrolladores inserten cualidades online en sus aplicaciones. El framework asegura la compatibilidad entre datos emitidos desde una máquina a otra, seas cuales sean las características de ambas. En un futuro cercano se ampliará el framework para dar soporte a aplicaciones web.

27 Conclusiones Para dar soporte web, se creará un servicio proxy que traduzca entre XML y los datos enviados y recibidos por los diversos servicios. Para las aplicaciones web cliente, se migrará parte de la funcionalidad del framework al lenguaje JavaScript.

28 Y por último... Una Demo

29 DHelloWorld Aplicación que emite una pareja x,y y es capturada por ella misma, las instancias de esa aplicación (locales o en red) y cualquier otra aplicación que capture este tipo de eventos. En la aplicación final solo se requieren unos pocos pasos para convertirla desde una aplicación local a una aplicación distribuida (con todo lo que ello implica).

30 DHelloWorld El método que imprime los valores en la etiqueta se ha sustituido por el envío de un evento (el envío del evento son 4 líneas). Se ha implementado un listener para el evento concreto anterior. La parte más compleja es realizar la acción, aunque esta se corresponde con lo que hacía el método que sustituimos anteriormente. En el fichero main se ha agregado setup_environment. Con esta única llamada, se inicializa todo lo que necesita el framework para trabajar.

31 DPaint Es una aplicación con la funcionalidad básica de un paint. La conversión a aplicación distribuida se realizó en menos de una hora! La comunicación entre dispositivos que aporten información de contexto puede llegar a realizarse en un tiempo parecido. Solo tendremos que definir los eventos, crear las acciones para los listeners y decidir si utilizaremos metainformación o no. Lo demás lo gestionará automáticamente el framework.