SOFIA es una arquitectura middleware que permite la interoperabilidad entre dispositivos independientemente de su plataforma a través de una ontología que modela el dominio de forma independiente del lenguaje. La arquitectura SOFIA consta de aplicaciones conocidas como KPs que se comunican con un SIB (Semantic Information Broker) que actúa como base de datos semántica compartida mediante mensajes XML estandarizados.

1. SOFIA Arquitectura SOFIA Soluciones Tecnológicas Jesús Fernández Gómez-Pimpollo – Ingeniero de Sistemas

2. INDICE 01 Introducción 02 Componentes de la arquitectura SOFIA 03 Papel de la ontología 04 Estado Actual SOFIA 05 Formato de Mensajes 06 Desarrollo 07 Application Development Kit (ADK)

3. SOFIA es una arquitectura de middleware para proveer interoperabilidad entre dispositivos, independientemente de la plataforma de estos. La interoperabilidad multiplataforma se consigue realizando un modelado del dominio concreto independiente del lenguaje, que permitirá a las aplicaciones identificar los conceptos tratados. El modelado del dominio independiente de la plataforma, se realiza con una ontología. En esta ontología se deben reflejar todas las clases identificadas así como sus propiedades y relaciones. En definitiva, una ontología es un fichero XML estandarizado, independiente del lenguaje. INTRODUCCIÓN / ¿QUÉ ES SOFIA?

4. En SOFIA, el entorno donde diferentes aplicaciones interoperan es conocido como SmartSpace. El núcleo de un SmartSpace son uno o mas SIB. Un SIB (Semantic Information Broker), es una base de datos semántica. En él se reflejan todos los conceptos existentes en el dominio (reflejados en la ontología) y su estado actual (instancias particulares). Todos estos conceptos son introducidos, actualizados y consultados por las aplicaciones. En cierto modo (aunque no es así) se puede interpretar como si las instancias de las clases residieran en el SIB, y fuesen compartidas por múltiples aplicaciones. Las aplicaciones que interoperan a través del SIB se denominan KP (Knowledge Processor). Estas aplicaciones trabajan con instancias de los conceptos relevantes del dominio para las que están diseñadas. Deben establecer una conexión con el SIB, introducir y actualizar sus propios instancias de elementos del dominio y consultar y subscribirse a los conceptos que le sean relevantes. De este modo, el SIB se convierte en el elemento intermedio de comunicación entre las aplicaciones. Componentes en arquitectura SOFIA

5. Componentes SOFIA (I) SIB KP Aplicación 1 KP Aplicación 3 KP Aplicación 2 KP Aplicación 4

6. En función de cómo se comportan los KPs con respecto a la información del SIB, se identifican los siguientes tipos: Producer: Aplicación que solo inserta información en el SIB. Consumer: Aplicación que solo recupera información del SIB. Prosumer: Aplicación que inserta y recupera información del SIB indistintamente. Componentes SOFIA (II)

7. El primer paso en la fase del diseño con SOFIA consiste en diseñar la ontología. Aquí se identifican todas las clases del dominio, sus propiedades y relaciones. SOFIA está diseñado para reconocer ontologías en formato OWL/RDF. Existen diversas herramientas para realizar este modelado, entre ellas, la mas utilizada por los desarrolladores de SOFIA es Protégé ( http://protege.stanford.edu ), que permite crear una ontologia simplemente partiendo de conocimientos propios de la Orientación a Objetos. El resultado es un fichero OWL. Cada KP, cuando es diseñado, incluye el subconjunto de conceptos (clases) de la ontología propios de su cometido, ignorando aquellos que le son irrelevantes. Este subconjunto se refleja en el KP como otro fichero OWL. Cuando un KP conecta con el SIB, envía a este su fichero OWL, de manera que el SIB puede identificar aquellas clases sobre las que el KP puede crear y mantener instancias interoperando de este modo con otros KPs. Papel de la ontología

8. La comunicación entre el SIB y las aplicaciones (KP’s) actualmente está contemplada mediante tres protocolos de comunicación, a través de los cuales, SIB y aplicaciones se intercambian un juego de mensajes XML. La implementación del SIB es independiente del protocolo de comunicación especifico, ya que la comunicación es implementada mediante Gateways específicos para cada protocolo, siendo el SIB y los Gateways componentes independientes entre sí. TCP/IP: El SIB se despliega en una máquina conectada a una red privada o incluso a internet y acepta conexiones de las aplicaciones a través de un puerto de la máquina. Bluetooth: El SIB se despliega en una máquina con capacidades Bluetooth, y acepta conexiones de las aplicaciones que estén en su rádio de acción. ZibBee: El SIB se despliega en una máquina con capacidades ZigBee en modo API, y acepta conexiones de las aplicaciones que estén en su radio de acción. Todos los protocolos pueden funcionar simultáneamente, de modo que una aplicación que se conecte al SIB vía TCP/IP, podrá interactuar con otra que lo haga vía Bluetooth. Estado actual SOFIA/Comunicaciones

9. Existen tres tipos de SIBs: OSGI SIB Smart M3 SIB RIBS Estado actual SOFIA/Tipos de SIBs

10. OSGI SIB La arquitectura de este tipo de SIB está basada en la plataforma OSGI ( http://www.osgi.org ). Se compone de un conjunto de Bundles (componentes OSGI) que permiten que sea fácilmente extensible en cuanto a sus capacidades, separando en distintos módulos el SIB, los gateways de conexión para los distintos protocolos y diferentes herramientas de diagnostico. La implementación OSGI sobre la que está desarrollado es Equinox ( www.eclipse.org/equinox ), por lo que la plataforma de ejecución será una máquina virtual de Java. Estado actual SOFIA/OSGI SIB (I)

11. Estado actual SOFIA / OSGI SIB (II) Java Virtual Machine OSGI Framework SIB Bundle Bluetooth Gateway Bundle TCP/IP Gateway Bundle SIB Viewer Bundle

12. SmartM3 SIB Concebido para ser ejecutado en entornos Linux, se compone de diversos procesos: SIB: Demonio que ejecuta el SIB Manejadores de transporte: Diversos demonios que implementan las distintas pasarelas por las que las aplicaciones se comunicarán con el SIB, (TCP/IP, NoTA…) Estado Actual SOFIA / SmartM3 SIB

13. RIBS SIB Implementación del SIB concebida para ejecutarse en entornos de prestaciones reducidas. Está basado en ANSI-C. Estado actual SOFIA / RIBS SIB

14. La comunicación entre el SIB y las aplicaciones, aparte del protocolo de conexión utilizado, está estandarizada mediante un conjunto de mensajes XML denominados SSAP. Estos mensajes permiten a las aplicaciones: Conectarse/desconectarse de un SIB Insertar/Actualizar/Borrar Información en un SIB Recuperar Información de un SIB Suscribirse/Darse de baja a determinadas clases en un SIB Notificar cambios desde el SIB a suscriptores Comunicación SIB – KP (Mensajes)

15. Los mensajes SSAP pueden clasificarse en 3 categorias distintas: REQUEST: Enviado desde el KP al SIB. CONFIRM: Enviado desde el SIB al KP en respuesta a un mensaje de REQUEST. INDICATION: Enviado desde el SIB al KP cuando ocurre un evento al que el KP está subscrito. Los mensajes lleva asociados el identificador del KP y del SIB intervinientes en la comunicación Un mensaje SSAP por parte del KP (REQUEST), siempre tiene una respuesta desde el SIB, indicando si la operación ha sido satisfactoria o no, por lo que cada mensaje SSAP tiene un identificador de transacción, que permite asociar las solicitudes a las respuestas. Comunicación SIB – KP (Mensajes)

16. Los mensajes SSAP tienen el siguiente formato: <SSAP_message> <node_id> Id del KP </node_id> <space_id> Id del SIB </space_id> <transaction_id> Numero de Transacción </transaction_id> <transaction_type> Tipo de mensaje </transaction_type> <message_type> REQUEST|CONFIRM|INDICATION </message_type> <parameter name= “&quot;> xxxxx </parameter> <parameter name= “xxxx&quot;> xxxxx </parameter> ········ </SSAP_message> Comunicación SIB – KP (Mensajes)

17. Conexión/Desconexión a un SIB: Aparte de la conexión física entre las máquinas donde se ejecutan el SIB y la aplicación por protocolo elegido, es necesario establecer una conexión lógica entre la aplicación y el SIB, de modo que se permita el intercambio de información entre ambos. Se realizan mediante las transacciones de tipo JOIN: Conexión al SIB LEAVE: Desconexión del SIB Para ambos tipos de transacciones, la iniciativa parte del KP. Mensajes SSAP KP SIB 1. Join/Leave (Request) 2. Join/Leave (Confirm)

18. Insertar/Actualizar/Borrar Información en un SIB: Son las operaciones a través de las cuales, una aplicación maneja la información que deja en el SIB disponible para el resto de las aplicaciones. Se realizan mediante las transacciones de tipo INSERT: Insertar nuevas instancias de objetos en el SIB UPDATE: Actualizar instancias de objetos ya existentes REMOVE: Borrar instancias de objetos Para todas ellas la iniciativa parte del KP Mensajes SSAP KP SIB 1. Insert/Update/Remove (Request) 2. Insert/Update/Remove (Confirm)

19. Recuperar Información de un SIB: Es la operación a partir de la cual, una aplicación puede ejecutar consultas sobre la información almacenada en un SIB. La consulta se realiza sobre una determinada clase, siendo devueltas todas las instancias que el SIB mantiene de la misma. Se realizan mediante transacciones de tipo QUERY La iniciativa para este tipo de transacción parte del KP: Mensajes SSAP KP SIB 1. Query (Request) 2. Query (Confirm)

20. Suscripción/De-suscripción : Son las operaciones que permiten a una aplicación suscribirse y desuscribirse a determinadas clases en el SIB, de modo que cuando cualquier aplicación notifique algo relevante en relación a una instancia de estas clases, el SIB automáticamente enviará dicha instancia de clase al conjunto de aplicaciones suscritas para que puedan evaluar el cambio. Se realizan mediante transacciones de tipo: SUBSCRIBE: Subscripción a una clase. UNSUBSCRIBE: Desubscripción de una clase La iniciativa para este tipo de transacción parte del KP: Mensajes SSAP KP SIB 1. Subscribe/Unsubscribe (Request) 2. Subscribe/Unsubscribe (Confirm)

21. Suscripción (Indicaciones) : Es la operación de Subscripción mediante la cual, un SIB informa a todos los KPs subscritos a una determinada clase, de los cambios que otros KPs realicen en alguna de las instancias de dicha clase. Se realizan mediante una transacción de tipo SUBSCRIBE, pero un tipo de mensaje INDICATION. En este caso es iniciativa del SIB realizar la correspondiente transacción, y no requiere respuesta por parte del KP. Mensajes SSAP KP SIB 2. Subscribe (Indication)

22. Se puede encontrar mas información sobre los parámetros específicos de los mensajes SSAP en el documento adjunto SSAP_15032010.pdf Mensajes SSAP

23. Cualquier aplicación puede convertirse en un KP, siempre que se conecte adecuadamente a un SIB y utilice el protocolo de mensajes SSAP para interactuar con este. Por lo que no existen restricciones en cuanto al lenguaje a utilizar, ya que SSAP es tan solo un formato de mensajes XML. De todos modos, para facilitar el desarrollo a los programadores, se han diseñado APIs de programación en Java y C, que abstraen a los desarrolladores de los detalles específicos de comunicación con el SIB, constituyendose en la parte cliente del middleware de comunicación entre aplicaciones, permitiendo a los desarrolladores centrarse solo en la lógica de la aplicación. Desarrollo (I)

24. Este API son una serie de librerías que abstraen al programador de los detalles de bajo nivel de la arquitectura SOFIA, proporcionando un conjunto de interfaces de programación de alto nivel mediante el que es posible desde un KP: Descubrir SIBs en el radio de acción de la aplicación. Gestionar el SIB al que se conecte con un conjunto de funciones. Gestionar todos los elementos de la ontología (y por tanto del problema) como objetos. Gestionar las suscripciones mediante el patrón de diseño Listener. Desarrollo (II)

25. En SOFIA , se han desarrollado una serie de herramientas para facilitar el trabajo de los programadores. Estas herramientas se conocen como ADK (Application Development Kit). Son una serie de plugins instalables en el popular entorno de desarrollo Eclipse, por lo que los programadores tienen la facilidad de desarrollar las aplicaciones asistidos por este entorno de desarrollo integrado. Application Development Kit

26. Las herramientas que se integran en el ADK son: Plugin para creación de proyectos SOFIA: Crea en el espacio de trabajo un proyecto con las APIs y librerias elegidas en el asistente(C, Java, Bluetooth, TCP/IP….) Plugin para añadir las clases de la ontologia a la aplicación: Permite seleccionar los elementos de la ontologia que son relevantes para la aplicación, Indicando a su vez si son elementos para producir (insertar al SIB), consumir (recuperar o ser notificado desde el SIB) o ambos. Una vez seleccionados estos conceptos, el propio ADK se encarga de traducirlos a clases y añadirlas al proyecto. OSGI SIB: SIB integrado en el ADK, permite realizar pruebas con las aplicaciones, conectándolas a este SIB. Application Development Kit (II)

27. SIB Viewer: Permite comprobar el estado del SIB integrado en el ADK, ver las aplicaciones conectadas a él, las subscripciones realizadas sobre él, así como la información que tiene almacenada en cada momento. TCP/IP Gateway: Pasarela de acceso al SIB integrado en el ADK mediante el protocolo TCP/IP. Bluetooth Gateway: Pasarela de acceso al SIB integrado en el ADK mediante el protocolo Bluetooth. Application Development Kit (III)

28. Application Development Kit (III)

29. Jesús Fernández Gómez-Pimpollo Soluciones Tecnologicas / Innovacion Tecnológica [email_address] Avda. de Bruselas 35 28108 Alcobendas, Madrid España T +34 91 480 50 00 F +34 91 480 50 80 www.indra.es