sofia indra presentation to aicia
Post on 13-Dec-2014
615 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
top related