SOFIA

Arquitectura SOFIA

Soluciones Tecnológicas

Jesús Fernández Gómez-Pimpollo – Ingeniero de Sistemas

Tít

ulo

de

la p

rese

nta

ció

n /

F

ive

lam

pst

and

s co

mfo

rtab

ly t

ickl

ed

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)

Tít

ulo

de

la p

rese

nta

ció

n /

F

ive

lam

pst

and

s co

mfo

rtab

ly t

ickl

ed

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?

Tít

ulo

de

la p

rese

nta

ció

n /

F

ive

lam

pst

and

s co

mfo

rtab

ly t

ickl

ed

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

Tít

ulo

de

la p

rese

nta

ció

n /

F

ive

lam

pst

and

s co

mfo

rtab

ly t

ickl

ed

5

Componentes SOFIA (I)

SIB

KPAplicación 1

KPAplicación 3

KPAplicación 2

KPAplicación 4

Tít

ulo

de

la p

rese

nta

ció

n /

F

ive

lam

pst

and

s co

mfo

rtab

ly t

ickl

ed

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)

Tít

ulo

de

la p

rese

nta

ció

n /

F

ive

lam

pst

and

s co

mfo

rtab

ly t

ickl

ed

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

Tít

ulo

de

la p

rese

nta

ció

n /

F

ive

lam

pst

and

s co

mfo

rtab

ly t

ickl

ed

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

Tít

ulo

de

la p

rese

nta

ció

n /

F

ive

lam

pst

and

s co

mfo

rtab

ly t

ickl

ed

9

Existen tres tipos de SIBs:

OSGI SIB

Smart M3 SIB

RIBS

Estado actual SOFIA/Tipos de SIBs

Tít

ulo

de

la p

rese

nta

ció

n /

F

ive

lam

pst

and

s co

mfo

rtab

ly t

ickl

ed

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)

Tít

ulo

de

la p

rese

nta

ció

n /

F

ive

lam

pst

and

s co

mfo

rtab

ly t

ickl

ed

11

Estado actual SOFIA / OSGI SIB (II)

Java Virtual Machine

OSGI Framework

SIB Bundle

Bluetooth Gateway Bundle

TCP/IP Gateway Bundle

SIB Viewer Bundle

Tít

ulo

de

la p

rese

nta

ció

n /

F

ive

lam

pst

and

s co

mfo

rtab

ly t

ickl

ed

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

Tít

ulo

de

la p

rese

nta

ció

n /

F

ive

lam

pst

and

s co

mfo

rtab

ly t

ickl

ed

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

Tít

ulo

de

la p

rese

nta

ció

n /

F

ive

lam

pst

and

s co

mfo

rtab

ly t

ickl

ed

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)

Tít

ulo

de

la p

rese

nta

ció

n /

F

ive

lam

pst

and

s co

mfo

rtab

ly t

ickl

ed

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)

Tít

ulo

de

la p

rese

nta

ció

n /

F

ive

lam

pst

and

s co

mfo

rtab

ly t

ickl

ed

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=“">xxxxx</parameter>

<parameter name=“xxxx">xxxxx</parameter>

········

</SSAP_message>

Comunicación SIB – KP (Mensajes)

Tít

ulo

de

la p

rese

nta

ció

n /

F

ive

lam

pst

and

s co

mfo

rtab

ly t

ickl

ed

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)

Tít

ulo

de

la p

rese

nta

ció

n /

F

ive

lam

pst

and

s co

mfo

rtab

ly t

ickl

ed

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 SIB1. Insert/Update/Remove (Request)

2. Insert/Update/Remove (Confirm)

Tít

ulo

de

la p

rese

nta

ció

n /

F

ive

lam

pst

and

s co

mfo

rtab

ly t

ickl

ed

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 SIB1. Query (Request)

2. Query (Confirm)

Tít

ulo

de

la p

rese

nta

ció

n /

F

ive

lam

pst

and

s co

mfo

rtab

ly t

ickl

ed

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 SIB1. Subscribe/Unsubscribe (Request)

2. Subscribe/Unsubscribe (Confirm)

Tít

ulo

de

la p

rese

nta

ció

n /

F

ive

lam

pst

and

s co

mfo

rtab

ly t

ickl

ed

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 SIB2. Subscribe (Indication)

Tít

ulo

de

la p

rese

nta

ció

n /

F

ive

lam

pst

and

s co

mfo

rtab

ly t

ickl

ed

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

Tít

ulo

de

la p

rese

nta

ció

n /

F

ive

lam

pst

and

s co

mfo

rtab

ly t

ickl

ed

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)

Tít

ulo

de

la p

rese

nta

ció

n /

F

ive

lam

pst

and

s co

mfo

rtab

ly t

ickl

ed

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)

Tít

ulo

de

la p

rese

nta

ció

n /

F

ive

lam

pst

and

s co

mfo

rtab

ly t

ickl

ed

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

Tít

ulo

de

la p

rese

nta

ció

n /

F

ive

lam

pst

and

s co

mfo

rtab

ly t

ickl

ed

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)

Tít

ulo

de

la p

rese

nta

ció

n /

F

ive

lam

pst

and

s co

mfo

rtab

ly t

ickl

ed

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)

Tít

ulo

de

la p

rese

nta

ció

n /

F

ive

lam

pst

and

s co

mfo

rtab

ly t

ickl

ed

28

Application Development Kit (III)

Tít

ulo

de

la p

rese

nta

ció

n /

F

ive

lam

pst

and

s co

mfo

rtab

ly t

ickl

ed

29

Jesús Fernández Gómez-PimpolloSoluciones Tecnologicas / Innovacion Tecnológica jfgpimpollo@indra.es

Avda. de Bruselas 35 28108 Alcobendas, Madrid EspañaT +34 91 480 50 00F +34 91 480 50 80www.indra.es