Soporte técnico para una instalación de arte...

13. Descripción de la solución

El siguiente esquema representa la Estructura Detallada de Trabajo, con relación detodos los elementos que satisfacen los Requisitos para el soporte técnico proyectadodel Proyecto.

Figura 13.1.: Estructura Detallada de Trabajo de la aplicación de Soporte Técnico

En apartados anteriores, hemos explicado la técnica empleada para la elaboraciónde esta Estructura, así como su utilidad tanto para la organización del trabajo comopara la valoración del alcance cubierto por el desarrollo final del proyecto. Con ello, seha intentado justificar la clasificicación de los entregables, inspirada en el paradigmaSOA trasladada al marco de gestión del PMBOK. Partiendo de esta base, queda porjustificar el contenido así organizado.

El propósito de este capítulo es introducir este contenido, describiendo el origen y laaportación de cada componente en la aplicación. Para ello, vamos a recorrer de nuevolos argumentos del proyecto, comenzando por los requisitos y el alcance propuesto,para presentar la solución teórica completa de la que se desprende directamente laestructura anterior.

185

Capítulo 13 Descripción de la solución

13.1. Diseño

A continuación, vamos a desarrollar un modelo de aplicación que responde al Objetodel proyecto. Vamos a analizar una vez más los antecedentes y requisitos del Sopor-te Técnico para ir identificando los componentes que cubren el alcance del sistemapropuesto, introduciendo las herramientas para su desarrollo y verificación. Anali-zaremos la lógica de este sistema, concebida globalmente pero distribuida en blo-ques (los ya presentados: red de sensores, estación servidor, red multimediae interfaz de usuario) y profundizaremos en los mecanismos de integración y lastécnicas aplicables para garantizar el comportamiento y las prestaciones requeridasa partir de las tecnologías de implementación.Una parte muy importante de estacontribución vendrá con el estudio de los aspectos generales de comunicación en-tre los bloques del Soporte. Al tratarse de una de las partes críticas del proyecto,profundizaremos en los aspectos de protocolos que caracterizan la configuración delsistema y el modelo de explotación, introduciendo una visión general del Soporte,como redes de nodos interconectados, que servirá como punto de partida para ladescripción de las guías de la arquitectura software que se detallan en el capítulosiguiente.

El capítulo se ha organizado conforme a la metodología propuesta en el Capítulo IV.Partimos del Alcance para elaborar la relación de los casos de uso que desarrollanel proyecto en un entorno de aplicación. El objetivo de la etapa de diseño es definirtodos los elementos teóricos y de análisis necesarios para proceder, en el siguienteapartado, a la descripción precisa de la lógica del Soporte, en términos que corres-pondan directamente a componentes de programación. Para completar esta tarea,necesitamos primero aclarar cómo se traslada el conocimiento de los referentes delSoporte Técnico en el diseño de la solución, sintetizando un modelo teórico de loselementos del sistema y un esquema general que ubique claramente estos elemen-tos en la aplicación a desarrollar. Con estos datos, estaremos ya en disposición depresentar, en la parte final del capítulo, la estructura del profile de la aplicación,que sirve como modelo de intercambio de todos los elementos del Soporte, así comolos aspectos fundamentales de la comunicación entre bloques y componentes, ade-lantando algunas especificaciones de los protocolos necesarias para comprender lascaracterísticas de la arquitectura y la definición de los contratos de servicio.

13.1.1. Casos de uso

Un caso de uso es una secuencia de interacciones que se desarrollarán entre unsistema y sus actores en respuesta a un evento que inicia un actor principal sobreel propio sistema. Los casos de uso pueden describirse gráfica y textualmente. Losdiagramas enfatizan la relación entre los diferentes actores y casos en un escenarioconcreto, mientras que la descripción textual captura la relación entre los actoresy el sistema, pudiendo resumir sus características o abordarlas con profundidad y

186

13.1 Diseño

extensión. UML recoge los casos de uso dentro de sus herramientas de descripciónde comportamiento y define los elementos y las reglas para la representación dediagramas; para la descripción textual, se han desarrollado multitud de plantillas,como por ejemplo la propuesta por Derek Coleman, de la Hewlet- Packard SoftwareInitiative1.

Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema,al mostrar cómo reacciona a eventos que se producen en su ámbito. Por esta razón,el punto de partida para el diseño del sistema debe ser una identificación de loscasos de uso que responden a los Requisitos para el soporte técnico proyectado.En este punto, podemos aprovechar esta herramienta para desarrollar el alcancedel Soporte Técnico de forma teórica, capturando en los Casos de Uso los eventos,actores, métodos y características planteados en elMarco Lógico del proyecto. Paraconseguirlo, necesitamos completar la información del Alcance con el conocimientoprevio de la instalación, sus posibles usos y perfiles de usuario, ya que en ellos vamosa identificar a los Actores del Soporte Técnico. El estudio del contexto ha servidocomo base para desarrollar en los Anexos el estudio de los casos de uso que modelaníntegramente el proceso de desarrollo de la obra de arte y su exposición. En unaprimera aproximación, se han identificado los Actores y casos de uso relacionadoscon el Soporte Técnico, descubriendo - como podíamos intuir - que hay tres perfilesinvolucrados en el sistema: el Creativo, el Visitante y el Integrador. Estos perfiles yahabían aparecido en la memoria, en la Tabla 8.1, donde, además de los tres actoresreconocidos, aparecen dos más que también van a dar un uso al sistema, comoveremos más adelante.

En el diagrama Figura 15.3, se condensa una descripción completa de la obra in-teractiva. Se trata de un diagrama muy completo, que recorre a vista de pájaroun proceso multidisciplinar que supera el alcance del Proyecto. El Soporte Técnicoabarca sólo una parte de estos casos, por lo que se han estudiado en un diagramaseparado los casos de interés para determinar si se trata de casos reales - que respon-den directamente a un requisito del proyecto - o, por el contario, son contenedoresque agrupan uno o varios escenarios. Del estudio de los diagramas Figura 15.6 yFigura 15.7 se desprende que el Soporte implementa siete Casos de Uso, que in-corporan además una serie de especificaciones descritas en la Figura 15.8. Estasespecificaciones corresponden a carencias detectadas en la instalación de referenciaque se esperan corregir con el Soporte Técnico, lo que nos lleva de nuevo a los reque-rimientos del Proyecto, que cubre completamente esta lista y la amplía para incluiraspectos y características que superan las limitaciones del modelo de la aplicaciónoriginal.

El anterior grupo de casos se ha extraído del estudio de las características del Sopor-te Técnico que responden a un propósito específico, que es permitir que los Visitantespuedan pasear por la instalación y percibir cambios en la obra que están viendo. Sin

1http://www.engr.sjsu.edu/~fayad/current.courses/cmpe202-Fall2009/docs/lecture3/CmpE202-22-UC-Template-Ex-L3-3g.pdf

187


embargo, hay requisitos y actores de la aplicación que no se han mencionado en losanteriores diagramas, por lo que debemos plantear otras perspectivas o escenariosque completen el planteamiento. Para ello, en la sección Subsección 15.1.2, estudia-mos los usos de la instalación en escalas de tiempo alternativas. En primer lugar, alestudiar el comportamiento del sistema en el estado transitorio de apertura, encon-tramos uno de los actores secundarios de nuestra aplicación - el Guía - que invocanuevos casos de uso fundamentales para la puesta en marcha y la parada globaldel sistema. En un segundo diagrama, se han unificado todos los usos futuros delsoporte técnico, cuando ya ha cumplido su propósito como instalación, en los que seincluye tanto la posible conservación de la obra como la mejora (o modificación) dela aplicación de Soporte, apareciendo así el último actor del sistema, denominadoMantenimiento.Siguiendo la metodología de modelado por plantilla, recogemos a continuación loscasos de uso del Soporte Técnico:

Caso de uso Iniciar el sistema

Descripción Secuencia de procedimientos llevada a cabo por el Guía sobre el equipamiento del soportetécnico que permite la correcta habilitación del sistema

Actores Guía

Condiciones -

Pasos

1. Chequeo de alimentación

2. Encendido de estación PC

3. Encendido del Coordinador WSN

4. Encendido de hotspot / router WiFi

5. Arranque aplicación servidor en la estación

6. Cuando esté lista, encendido de la Pasarela WSN

7. Puesta en marcha de los elementos de la instalación (proyectores, cubos de luz...)

Variaciones Versión completa: Asistencia a la puesta en marcha por la pantalla del Coordinador WSN.Versión lite: Sin asistencia; solo mensaje de bienvenida.

Requisitos no

funcionales Configuración de red WSN

Configuración IP de equipos de red

Ajuste adecuado de elementos AV

Cuestiones abiertas -

Cuadro 13.1.: Caso de Uso: Iniciar sistema

188

13.1 Diseño

Caso de uso Habilitar el soporte técnico

Descripción Secuencia de arranque del programa principal que registra los servicios del sistema y rutina deejecución en bucle que se mantiene activa mientras el sistema permanezca encendido. Seencarga de mantener la integridad del sistema y la cohesión entre los bloques, estableciendo ymanteniendo la conexión entre dispositivos remotos (servicios).

Actores Integrador, Servidor

Condiciones Sistema iniciado manualmente

Pasos

1. Servidor

a) Núcleo del servidor

b) Resolución de depedencias

c) Estado de componentes

1) Servidor UPnP

2) Pasarela WSN

d) Estado de servicios

1) Escucha puerto serie

2) Escucha dispositivos UPnP

2. WSN

a) Coordinador. Establecimiento de red

b) Pasarela. Sesión remota de coordinador

c) Routers

1) Consistencia de red

2) Vecindad

3) Calibrado LQi

d) Atención a nodos móviles

3. Navegador de dispositivos

Variaciones -

Requisitos no

funcionales

-

Cuestiones abiertas Script de arranque global no definidoElementos de red UPnP (MediaServer, MediaRenderers) no implementados

Cuadro 13.2.: Caso de Uso: Habilitar Soporte Técnico

189


Caso de uso Localizar al Visitante

Descripción Seguimiento del movimiento de los nodos de visitante, asociando la posición estimada con lalocalización en una determinada zona de la instalación o “Set”

Actores Visitante, WSN

Condiciones

Soporte técnico habilitado y suscrito a la información del nodo visitante

Recibida información de posición suficiente

Pasos

1. Ráfaga de medida

a) Dispositivo móvil (nodo visitante) inicia diálogo con balizas de la red

b) Ecos de balizas (ráfaga)

c) Estimación de posición en el nodo móvil por mínimos cuadrados

d) Envío de actualización de posición

e) Compacta medidas de potencia recibidas de todas las balizas

f ) Envio de datos de última ráfaga

2. Inicia nuevo temporizador para medida y espera (pasiva) respuesta del servidor

a) Si vence el temporizador, repetir (1)

b) Si llega respuesta

1) Actualizar posición

2) ¿Etiqueta de zona?

a′ Limpiado de memoria

b′ Llamada al Device Set

Variaciones Versión completa: Envio de ráfagas largas con gestión del tiempo de envío y gestión remota delos parámetros del cicloVersión lite: Envío fijo de ráfagas simples, tiempos de servicio invariables

Requisitos no

funcionales

Métrica LQi (posición conocida de balizas, potencia de transmisión igual en todos los nodos)

Cuestiones abiertas Extremo consumidor (estación PC) no implementado. Arquitectura abierta a cualquier soluciónde localización.

Cuadro 13.3.: Caso de Uso: Localizar al Visitante

190

13.1 Diseño

Caso de uso Controlar el contenido

Descripción Capacidad de la aplicación para conocer en todo momento las características del mensaje queestá exhibiendo la instalación y manejar cualquier posible cambio de estado en el mensaje.Desde el punto de vista técnico, el control de contenido se implementa a través de la gestión deestado de los servicios distribuidos.

Actores Servidor

Condiciones

Soporte técnico habilitado

Mensaje definido y codificado

Almacenamiento de los elementos del mensaje conocido

Pasos

1. Identificación de las entidades que manejan contenido: dispositivos y descriptoressencillos.

2. Registro de zonas y localización de dispositivos por zona.

3. Por cada zona definida:

a) Verificar consistencia del estado. ¿Es correcto? Seguimos.

b) Verificar condiciones de salto del estado.

c) ¿Cambio de estado?

1) Localizar contenidos asociados al nuevo estado.

2) Comprobar que los dispositivos participantes soportan el nuevo estado

a′ Si no lo soportan y se pueden configurar, cargar parámetros ycontenido y seguir

b′ Si no lo soportan pero no se pueden configurar, abortar y volver alestado anterior

c′ Si lo soportan, seguimos

3) Cambio de contexto.

a′ Señales a dispositivos remotos

b′ Señales a dispositivos locales

c′ Limpieza de variables

4) Mientras esté activo, vuelte a (1)

Variaciones Versión completa: Envio de configuraciones complejas a la WSN, con secuencias de ambientesde regulación, lista de reproducción vídeo y gestión remota de temporización.Versión lite: Efectos de regulación sencillos y conmutación simple de película.

Requisitos no

funcionales Configuración de red multimedia / UPnP AV

Configuración de red WSN

Plantillas de descripción en los diferentes medios (ZigBee, UPnP).


Cuadro 13.4.: Caso de Uso: Controlar el contenido191


Caso de uso Definir modo de control

Descripción Definir estados y transiciones gobernados por el Control de Contenido

Actores Integrador, Servidor

Condiciones

Control de contenido operativo

Pasos

Definir zona: {Etiqueta; Miembros; Maestro de zona; Condiciones de acceso}

Definir estados de zona: para cada estado {Transiciones; Modo de reproducción;Secuencia activa}

• Transiciones: variables de entrada del sistema (visitante específico en la zona,número de visitantes en la zona, fecha / hora, número de visitantes por hora...}.

• Modos de reproducción (en bucle N veces, reproducir cuando... nueva condición,repetir N veces si..., etc).

• Secuencia activa: Lista de reproducción con marcas de sincronización para cadabloque registrado en el sistema (lista de películas para el bloque multimedia,escena de iluminación para el control de luces WSN).

Variaciones Versión completa: Acceso a listas de reproducción externas, lenguaje formal de descripción delas marcas de sincronización y los modos de reproducción, capacidad para elaborar nuevasvariables de control sobre los inputs del sistema.Versión lite: Efectos de regulación sencillos y conmutación simple de película, variables delcontrol definidas por el sistema, modos de reproducción simplificados.

Requisitos no

funcionales Integración de medios en el servidor (WSN, AV UPnP)

Cuestiones abiertas Observadores no implementados (conteo de visitantes, variables de flujo de visita).Definición clara de “zona” y diferenciarla de célula. a

Cuadro 13.5.: Caso de Uso: Definir modo de control

aUna zona no tiene por qué corresponderse con una célula de cobertura en ZigBee. Cada router establece una célula,dentro de la que todos los nodos móviles van a solicitar que los adopte como “padre” en la topologia WSN. Un routerimplementa un dispositivo LightCube y un nodo móvil implementa un dispositivo Visitante. Se cumple entonces queuna célula pertenece a un router y una zona a un LightCube, pero en una célula sólo puede hacer un router, mientrasque en una zona puede haber más de un LightCube. Un nodo móvil está registrado en todo momento en una únicacélula (se conecta a través de un router a la WSN) y en una única zona (pide permiso al LightCube que maneja lazona), pero dicha célula y dicha zona no tienen por qué coincidir en el mismo nodo.

192

13.1 Diseño

Caso de uso Reproducir el mensaje

Descripción Se confirma en el servidor que se han propagado hasta los extremos de acción del sistema lascondiciones del siguiente estado de la instalación (por zonas) y, de forma distribuida, se ejecutaen estos extremos la secuencia de órdenes apropiada, usando como referencia la señal de relojdifundida por la aplicación.

Actores Servidor, WSN

Condiciones

Modo de control de contenido configurado

Pasos

1. En el Servidor

a) Control Point UPnP:

1) Petición al MediaServer

2) Controlar asociación con uno (o varios) MediaRenderer

2. En la WSN

a) Preparación:

1) Maestro de Zona (LightCube): Difunde señal de cambio de estado +marca temporal para indicar el momento de transición.

2) Actores de Zona (LightCube): Verifican configuración del siguiente estado:Secuencia válida de niveles de iluminación

b) Ejecución:

1) Maestro: Al alcanzar la marca, comienza la ejecución de la escena. Alempezar cada ambiente, se envía una señal de cambio a la zona paraasegurar la sincronización.

2) Actores: Ejecutan la escena en el tiempo indicado, verificando las marcasde sincronización del Maestro para mantener un ritmo homogéneo.

c) Finalización:

1) Maestro envía información de final de escena al servidor.

Variaciones Versión completa: Difusión de sincronización controlable.Versión lite: Las escenas se simplifican a un único ambiente, por lo que no se precisasincronización.

Requisitos no

funcionales Configuración de red multimedia / UPnP AV

Configuración de red WSN

Cuestiones abiertas Elementos de red UPnP (MediaServer, MediaRenderers) no implementados

Cuadro 13.6.: Caso de Uso: Reproducir mensaje

193


Caso de uso Controlar Artefactos

Descripción Función del sistema para gobernar el equipamiento integrado en el soporte técnico, traduciendoel mensaje en acciones que produzcan resultados evidentes para el visitante

Actores WSN

Condiciones


Definición de reacciones implementada

Regla de medida para ubicar a los nodos visitante

Pasos

Identificación de los artefactos del sistema: Descriptores de nodo y características depotencia y transmisión de nodo.

Control de regulación de luz: PWM

Variaciones Versión completa: Regla PWM (pulso, amplitud) dinámicaVersión lite: Regla PWM fija

Requisitos no

funcionales Configuración de red WSN


Cuadro 13.7.: Caso de Uso: Controlar artefactos

194

13.1 Diseño

Caso de uso Definir reacciones

Descripción Descripción formal de los estados operativos y las transiciones entre estados de los dispositivosdel sistema

Actores Integrador, WSN, Servidor

Condiciones


Outputs del sistema definidos

Control de reproducción activo

Pasos -

Variaciones

Ambiente: nivel de intensidad + tiempo de transición.

Comportamiento: regulación de luz indivual por la distancia promedio de N visitantes,número de visitantes en zona...

Remoto: manejo remoto de intensidad desde el dispositivo de visitante (órdenesintroducidas por pulsadores)

Requisitos no

funcionales WSN operativa

Pasarela WSN - Servidor operativa


Cuadro 13.8.: Caso de Uso: Definir reacciones

195


Caso de uso Definir reglas de medida

Descripción Descripción formal de las variables capturadas de la observación del Visitante y del entorno quesirven como condición para el cambio de estado de los dispositivos del sistema

Actores Integrador, WSN, Servidor

Condiciones


Inputs del sistema definidos

Pasos -

Variaciones

Cualitativas:

• Permisos de acceso del nodo visitante

Cuantitativas:

• Estimación de la posición por nivel LQi• Conteo de nodos móviles por zona• Flujo de visitantes

• Variables físicas del entorno (luminosidad, temperatura, humedad...)

Requisitos no

funcionales WSN operativa

Pasarela WSN - Servidor operativa


Cuadro 13.9.: Caso de Uso: Definir reglas de medida

196

13.1 Diseño

Caso de uso Habilitar interfaz remota

Descripción Uso de la capa de presentación que permite al usuario del sistema acceder al estado de lainstalación y modificar su contenido a través de dispositivos de gestión específicos.

Actores Integrador, Creativo

Condiciones Soporte Técnico habilitado, Interfaz de ampliación habilitada.

Pasos

1. De la red al usuario: Recopilación de datos de estado y publicación a través de losdispositivos de gestión.

2. Del usuario a la red: Escucha de los eventos de entrada desde los periféricos del equipo,procesamiento del evento y generación de los mensajes o solicitudes pertinentes. Puedeterminar con una señal de confirmación o una respuesta completa por (1).

Variaciones Interfaz de usuario: Comandos en línea para depuración de dispositivos, logger de eventos enlínea, navegador de dispositivos UPnP.Red multimedia: Reproductores de vídeo sobre UPnP AVRed WSN: Monitorización de red por consola LCD del coordinador

Requisitos no

funcionales Librerías y recursos específicos: Cling Workbench, Apache Client / Server y otrasextensiones a Cling.

Memoria gráfica en el coordinador

Cuestiones abiertas Clientes / Servidor multimedia no definidos.

Cuadro 13.10.: Caso de Uso: Habilitar interfaz remota

197


Caso de uso Ajustar módulos

Descripción Mecanismos del Soporte Técnico que permiten al usuario de Mantenimiento acceder ymanipular los parámetros de configuración de componentes y servicios, en tiempo de ejecución.

Actores Integrador, Mantenimiento

Condiciones Soporte Técnico Habilitado, Interfaz de Aplicación, Navegador de Dispositivos, Línea deComandos

Pasos -

Variaciones Servidor: Exponer API de ajuste de los módulos por línea de comandos o publicar cadacomponente ajustable como un dispositivo UPnP en el navegador.Servicios remotos: Incluir en el servidor un Proxy de gestión por dispositivo (uno para cada nodode red) a través del navegador UPnP. Opcionalmente, se podrían ajustar algunos parámetros deservicio por la pantalla del Coordinador.

Requisitos no

funcionales Coordinador con memoria suficiente para programar la interacción de los botones.

Capacidad en los nodos para incluir los mensajes de configuración y asentimiento en elprotocolo.


Cuadro 13.11.: Caso de Uso: Habilitar ajuste de módulos

198

13.1 Diseño

En la siguiente tabla, se pondera el valor de los Casos de Uso para el Soporte. Sehan analizado desde el punto de vista de su aportación al Alcance del Proyecto ysu incidencia en el desarrollo, desglosada en un indicador del momento en el que seactivan y la frecuencia con que tienen lugar durante la ejecución de la aplicación;también se indica el peso estuctural del caso, relacionado con los puntos del alcanceque dependen de él y, por último, su valor de desarrollo, que se desprende de lavaloración subjetiva por parte del Promotor de los requisitos a los que da respuesta.

Caso de uso Alcance Frencuencia(Arranque)

Peso Valor

Habilitar soportetécnico

SCR.1, WSN.2, WSN.4 Continuo (Dorsal) ***** ****

Iniciar el sistema WSN.4, SCR.2a,SCR.2b

Transitorio inicial (Núcleo) ** ***

Localizar alvisitante

WSN.3 Periódico (Fase de Apertura) ** *

Controlar elcontenido

MMD.1b, SCR.2a,SCR.3

Periódico (Fase de Apertura) **** ***

Definir modos decontrol

WSN.1, MMD.1a Transitorio (Fase de Acceso) ** **

Reproducir elmensaje

MMD.2 Esporádico (Fase deApertura)

* *

Controlar artefactos SCR.2b, SCR.3 Continuo (Fase de Apertura) *** ***

Definir reacciones SCR.6, SCR.7 Puntual (Ajuste) ** **

Definir reglas demedida

SCR.7 Puntual (Ajuste) ** **

Habilitar Interfazremota

WSN.6, SCR.6 Continuo (Fase de Acceso) **** ****

Habilitar API deaplicación

SCR.5 Continuo (Ajuste) *** ****

Habilitar ajuste demódulos

WSN.5, SCR.4 Continuo (Ajuste) * **

Cuadro 13.12.: Identificación de los casos de uso generales que cubren las carenciasdel proyecto base

199


13.1.2. Modelo conceptual

La definición de los casos de uso nos sirve para caracterizar las respuestas del sistemadesde el punto de vista de sus usuarios. Hemos identificado los actores del sistema yuna lista de casos que cubre los puntos del Alcance del Proyecto.Los escenarios documentados describen los usos para los que se ha pensado el sopor-te técnico y son una buena herramienta gráfica para facilitar la comprensión de laaplicación a sus promotores. Sin embargo, a medida que abandonamos la descripcióngenérica de los pasos y variaciones recogidos en cada caso de uso, resulta evidenteque son un recurso válido para capturar los requisitos generales y los grandes blo-ques funcionales, pero necesitamos otros métodos para profundizar en el diseño delsistema.Con este fin, se presenta a continuación un modelo conceptual que trata la aplicacióndesde el punto de vista de las estructuras internas de almacenamiento e intercambio.A lo largo de la sección, volveremos sobre los casos de uso y todas las entidadesque participan en su implementación para organizar estas ideas de diseño en unaestructura de información que sea consistente y eficaz. Una vez hayamos conseguidoeste objetivo, estaremos en disposición de tratar la visión del sistema por serviciosy los aspectos de negociación y traducción de datos que precisa la arquitecturadistribuida del Soporte.Esta sección recorre los cuatro niveles de abstracción en los que se ha dividido el mo-delo de datos. Primero, haremos una clasificación de todas las entidades simbólicasque se han mencionado hasta ahora y que participan en los casos de uso. Con estaclasificación, podremos caracterizar los atributos y las restricciones para cada enti-dad clasificada e introducir así el modelo de aplicación, basado en una plataforma deservicios sobre la solución de integración de redes para desarrollar los casos de usoanteriores. Como tendremos ocasión de ver, uno de los aspectos fundamentales enesta propuesta es la definición de los mecanismos de presentación y negociación entreagentes, por lo que abordaremos también el modelo de intercambio y representaciónque van a compartir los servicios del Soporte, caracterizado en el denominado Profilede aplicación. Por último, en las raíces del modelo, nos centraremos en la identifica-ción de los agentes de servicio, denominados Dispositivos, que representan entidadesde la Ontología y son los actores internos del sistema, participando en la realizaciónde los Casos de Uso y sirviendo como nudo de conexión de todos los conceptos an-teriores y punto de partida para la especificación de las funciones incorporadas a laarquitectura del Soporte Técnico.

13.1.2.1. Ontología

La implementación de los casos de uso requiere una estructura de datos ajustadaa la naturaleza y las características de una aplicación AmI, siguiendo además unpatrón que sea modular y escalable. Estas condiciones apuntan a una jerarquía de

200

13.1 Diseño

información con varios niveles de abstracción, con su base en las líneas de captaciónde los sensores y los comandos de los efectores del sistema y su cima en la descripciónpuramente simbólica de las entidades que participan en el proceso de interacciónartística y las condiciones que lo controlan.Necesitamos un modelo adecuado para gestionar esta complejidad, que podamosaplicar y trasladar sin dificultad a la definición de cada interfaz de servicio, quenos sirva para orientar la arquitectura de los componentes que se van a desarrollaren cada bloque del sistema, que aporte las condiciones de compatibilidad y losmecanismos de traducción imprescindibles para conseguir la interoperabilidad deconjunto y, en definitiva, que aporte un lenguaje eficaz para aprehender los conceptosde las fases previas de análisis e identificación. Con esta herramienta, podremos darun tratamiento unívoco y consistente a las especificaciones del proyecto y desarrollarla mejor solución posible.

Aproximación a la ontología El concepto de ontología ha aparecido varias vecesa lo largo de esta Memoria, relacionado siempre con el diseño de sistemas expertos.Recuperamos aquí la definición del término que propone Antonio Coronato ([8]):una ontología es una especificación formal y explícita de una conceptualizaciónacordada.En su trabajo, Coronato desarrolla un formalismo de diseño para los sistemas AmI,orientado a reducir el impacto de errores de conceptualización y de captación derequisitos en las etapas más tempranas del proyecto. Para ello, propone la utilizaciónde una ontología, con la que consutrir un vocabulario específico para el sistema y,con ello, eliminar cualquier ambigüedad concerniente a las entidades del dominiode aplicación. De forma general, se plantea un método ordenado para concretar lasespecificaciones de la aplicación, a través del cual se va a hacer evidente la ubicaciónde todas las entidades dentro de la ontología. Los pasos para alcanzar este modelode aplicación serían los siguientes:

1. Modelado informal

a) Boceto del escenario.

b) Propiedades generales.

2. Modelado estructural

a) Definición de las entidades.

b) Definición del dominio.

3. Modelado conductual

a) Identificación de movimientos.

b) Identificación de actividades.

c) Identificación del contexto.

4. Verificación

201


5. (Evaluación e iteración)

Siguiendo un camino alternativo, hemos recorrido con el estudio de los casos deuso los tres primeros subapartados del modelado, acumulando una gran cantidad deelementos que difícilmente podíamos clasificar y relacionar de forma efectiva. Ahora,con la ayuda de esta metodología, podemos ordenar todos esos conceptos, estable-ciendo un marco de referencia con el que podremos volver al Alcance del sistemay con igual facilidad avanzar hacia la definición de las estructuras de la aplicación,manteniendo en el recorrido un mismo lenguaje, en el que estarán recogidos sinambigüedad todos los elementos que son relevantes para la resolución del proyecto.

Ontología del Soporte Técnico Muy rápidamente, vamos a recordar todas las“entidades” que se han presentado como parte del sistema y que participan en al-guna de las intervenciones del proyecto, en alguno de los bloques de la solución ocomo agentes en uno de los casos de uso: tenemos un proyecto de referencia (“TheBOX”), del que se ha recuperado la configuración de una red de sensores ZigBeecon la que se está rastreando el movimiento de los visitantes en torno a una insta-lación interactiva, que está compuesta por elementos fijos capaces de crear efectosde luz, bien por la regulación directa de intensidad de un grupo de luminarias, bienmediante una vídeo - proyección monumental. La señal que excita este sistema es laposición de los visitantes, que portan un dispositivo móvil comunicado con la red desensores; esta información es procesada por el soporte técnico de la obra para crearefectos multimedia coordinados siguiendo una programación definida por el propioartista. Para describir y controlar estos comportamientos, se definen zonas dentrode la instalación, en las que tienen lugar dinámicas sincronizadas en respuesta alas acciones del visitante. A pesar de todo el esfuerzo por hacer que el sistema seaautónomo, se hace necesario por último el apoyo de otros agentes, encargados desupervisar el arranque del sistema y comprobar el estado de los dispositivos y laconfiguración de la aplicación.Podemos clasificar todos estos conceptos, asignándolos a alguna de las clases pro-puestas por Coronato, para caracterizar la ontología del Soporte Técnico. Paraello, se han tomado las categorías generales introducidas en el método (dominio,entidad, propiedad, movimiento, actividad, contexto) y se han desarrollado conformea las peculiaridades del proyecto, generando el siguiente esquema conceptual:El esquema anterior aporta toda la información necesaria para identificar los “ele-mentos” que participan en el modelo conceptual del Soporte Técnico. Toda la aplica-ción va a estar acotada al dominio de la instalación, que es el horizonte de desarrollopara el Soporte Técnico y es, a su vez, la propia obra una vez expuesta. El proyectohereda de la instalación sus propiedades espaciales (dimensiones, entorno de la obra,emplazamiento y localización de la exposición) y temporales (horario, duración de lavisita). Dentro de este espacio de trabajo, la aplicación va a desarrollarse en una di-mensión material, capturada por los elementos de la categoría “recursos”, además deuna dimensión funcional, recogida en la definición de ubicaciones (“localizaciones”),

202

13.1 Diseño

Figura 13.2.: Esquema de elementos de la ontología de la aplicación

actores (“usuarios”) e hilos de ejecución (“actividades”).

Como vemos, se ha sustituido en este esquema la categoría “entidad” por contene-dores más ajustados a los de casos de uso, designando como artefactos a los compo-nentes de la instalación que transmiten el mensaje de la obra y como equipos a losque participan en la gestión interna del contenido. Las propiedades más relevantesse han repartido por el esquema (marcadas con un color más claro), asociadas a loselementos con los que mantienen mayor afinidad. Algunos de estos elementos hansido tan sólo mencionados hasta este punto, pero comenzarán a cobrar protagonismodesde la perspectiva de este esquema lógico. Para una mayor claridad, gran partede los elementos recogidos en este esquema se han definido en una sección separadade la Memoria (ver Capítulo 11).

A partir de la clasificación anterior, llegamos a la ontología:

La ontología del Soporte Técnico no es más que un diagrama entidad - relación en elque los elementos han sido identificados y clasificados de acuerdo con el paradigmaAmI y las relaciones han sido establecidas para capturar el dominio de datos quesoporta los Casos de Uso implementados por el Soporte.

Podemos recorrer este modelo de datos siguiendo, una vez más, el sentido del pro-pósito artístico: desde el punto de vista del creativo, un Soporte Técnico para unaobra de arte interactiva debería ser una herramienta que, en primera instancia, le fa-cilitara una aplicación desde la que poder gestionar los equipos de reproducción AVy el comportamiento del sistema en su conjunto, como respuesta a la acción de losvisitantes. Para conseguir este objetivo, se va a dotar a la instalación de un equipoprincipal (servidor), encargado de la gestión central de servicios (pequeñas “aplica-ciones” que facilitarán la coordinación de los efectos de luz y vídeo). Para cumplir

203


Figura 13.3.: Ontología propuesta para el proyecto

este desempeño, el servidor debe estar conectado a los medios que hacen posible elconocimiento de la posición del visitante y los dispositivos capaces de reproducirlos contenidos descritos en las “secuencias de interacción”. En capítulos anteriores,hemos llegado a una solución tecnológica única para la localización y el control deluces, basada (como el referente principal de este Proyecto) en una red inalámbri-ca de tarjetas ZigBee; también hemos apuntado a una red multimedia basada enUPnP, de ahí que los elementos de acción y coordinación AV de nuestro sistemahayan tomado los nombres con los que UPnP AV presenta estas entidades dentro desu modelo de servicio. A partir de estas decisiones de diseño, se comprende que elservidor deba usar un dispositivo intermedio (la pasarela) para conectarse con la redWSN, que se despliega desde un nodo central (el coordinador), formando una topolo-gía de nodos con capacidades y funciones distintas: por una parte, tendremos nodoscon capacidades de red completas (“motes FFD”, también denominados “routers”),que sirven como cubos de luz y que, además, participan en la distribución espacialde la instalación en “zonas”; en el otro extremo, tendremos nodos con capacidadeslimitadas (“motes RFD” o “módulos”), que son facilitados a algunos visitantes paraconocer su posición y seguir sus movimientos.

A la luz de este modelo, parece claro que el Soporte Técnico debe estar diseñado

204

13.1 Diseño

de tal forma que el servidor pueda conocer, a través de los nodos WSN, los cambiosen la posición de los visitantes “localizados” y, al mismo tiempo, se encargue decoordinar el comportamiento de equipos WSN y equipos AV para que se manifiestela configuración establecida por el artista. Para conseguir fundamentalmente estedoble objetivo, con todas las características que hemos analizado, introducimos acotinuación el modelo de aplicación.

13.1.2.2. Modelo de aplicación

Un sistema con las características del Soporte Técnico admite soluciones muy dis-tintas, pero la línea marcada en este Proyecto nos lleva a apostar por un modelo deaplicación única, que contenga el dominio lógico descrito en la ontología y com-bine adecuadamente las características de inteligencia ambiental y diseño orientadoa servicio para ofrecer una solución eficaz a los casos de uso. Los propios casosincorporan la posibilidad de modificar las prestaciones del Sopore Técnico, tantopara construir una solución fijada a unas condiciones de trabajo como para ampliarel repertorio de funcionalidades, por lo que no estamos hablando de una aplicaciónfinal, en tanto que el Soporte Técnico no es un producto software terminado. Es-ta condición del Soporte Técnico no es contradictoria con un modelo de aplicaciónúnico, ya que el sistema que hemos esbozado está basado en una composición sobrebloques claramente definidos y una lógica uniforme que, además, facilita la centra-lización de la gestión en un nodo - el Servidor - que es clave en la interoperabilidadde todos los componentes.Aceptando que los requisitos del Soporte tienen una solución efectiva en un modelode aplicación, hemos visto que la amplitud de los usos recogidos por el sistema estan grande que una parte del mismo debe quedar abierta. Por poner un caso, el mo-vimiento del espectador, con las restricciones de camuflaje tecnológico y coste cero,hacen que el desplazamiento sólo pueda ser percibido mediante procesos indirectos,como la medida de calidad del enlace radio de un dispositivo portátil que acompañeal visitante. Esta única entrada debe desencadenar una cascada de procesos concu-rrentes que actúan, finalmente, sobre un conjunto de dispositivos que deben seguirun comportamiento no definido a priori (no hemos definido los “movimientos” comoparte de la ontología; tan sólo se ha introducido el concepto de “zona” como basepara el modelo de movimientos que va a definir el artista). Todos los parámetros delsistema, todas las variables que participan en reglas o comportamientos, derivan dela posición de los elementos - visitantes o parte de la obra - , que queda descritaen un espacio de coordenadas que se extiende por toda la instalación y tiene sucentro en el nodo Coordinador de la WSN. Vemos aquí cómo se mezclan caracterís-ticas muy concretas sobre la localización y naturaleza de los datos y la ubicación delas funciones centrales con una descripción incompleta del comportamiento final, loque se traduce en una solución abierta, no incompleta ni indeterminada, ya que laaplicación dispone de reglas y herramientas para definir todos estos detalles. Éstees, quizás, el caso que presenta con mayor claridad las peculiaridades por las que

205


definimos el modelo del Soporte Técnico como una infraestructura de integraciónpara una plataforma abierta de servicios, orientada al desarrollo de instalaciones dearte interactivo.

Por concluir el razonamiento anterior, descartando otros modelos de desarrollo dema-siado pequeños (utilidad, plugin) o demasiado grandes (sistema operativo, lenguajede programación), el Soporte Técnico responde a un diseño que combina un modelode datos derivado de la aplicación artística interactiva con mecanismos de inter-operabilidad entre redes de sensores y actuadores. Sobre esta infraestructura, quegarantiza la cohesión del sistema, se apoya la verdadera aplicación, que se despliegaa través de los denominados servicios.

Definición de servicio La Organización para el Avance de los Estándares de Infor-mación Estructurada (OASIS, responsable, entre otros estándares, de CMIS, DITAy OpenDocument) define un servicio como un mecanismo que permite el acceso auna o más capacidades, facilitado por medio de una interfaz prescrita y conforme alas condiciones y términos de uso especificados en el descritor del mismo, denomi-nado “contrato”. Ésta es la definición más completa y general disponible, frente aotras que conciben los servicios, simplemente, como componentes software de altonivel desarrollados bajo un paraguas de principios con una clara orientación Web,de aplicación en entornos empresariales.

Con esta noción de servicio como mecanismo de acceso a una facilidad regulada y es-tandarizada, el diseño orientado a servicio se define como una práctica de ingenieríasoftware aplicable en la etapa de diseño que busca capturar las especificaciones fun-cionales de una aplicación en servicios, siguiendo una serie de principios2, reflejadosen la Tabla 13.13.

Partes del Sistema Un conjunto de servicios necesita de una infraestructura paracomponer una aplicación. No existe un consenso sobre las características de estainfraestructura, pero, en general, debe dar soporte de comunicación y consistencia alos servicios integrados, desempeñando todas las funciones de las capas OSI, desdela conectividad física entre medios.

En la práctica, SOA prescribe cuatro tipos de infraestructuras de aplicación, que yapresentamos en este Proyecto al describir la Metodología. De los cuatro modelos,el que más se aproxima al Soporte Técnico es la denominada Infraestructura deComposición Servicios, que incorpora todos los componentes de integración - dri-vers, lógica de dominio y conexión a recursos compartidos - y los pone a disposiciónde una capa de componentes de servicio orquestados según el modo operativo delsistema. Podemos ver una clara diferenciación entre los componentes que participanen la infraestructura y los componentes que colaboran en la composición de servicios

2http://serviceorientation.com/index.php/serviceorientation/index

206

https://www.oasis-open.org/

13.1 Diseño

Contrato de Servicio Todos los servicios residentes en el mismo inventario deben ser compatiblescon los mismos estándares en la descripción de su Contrato (su especificación formal).

Acoplamiento débil Los contratos de servicio deben imponer pocos requisitos para la conexión delconsumidor y deben encontrarse naturalmente desacoplados de los recursos de su entorno.

Abstracción El contrato de servicio sólo debe contener información esencial; recíprocamente, losdatos conocidos de un servicio deben limitarse a lo que se publica en su contrato.

Reutilizado Los servicios contienen y expresan una lógica “agnóstica” y pueden ubicarse comorecursos reutilizables.

Autonomía Los servicios ejercen un fuerte control sobre su entorno en tiempo de ejecución.

Descubrimiento Los servicios son complementados por información en metadatos a través de laque pueden ser eficazmente descubiertos e interpretados.

Composición Los servicios son partes eficaces de cualquier composición, independientemente desu tamaño y complejidad.

Delegación Los servicios minimizan el consumo de recursos, difiriendo la gestión de sus variablesde estado cuando es necesario.

Cuadro 13.13.: Principios de diseño SOA

por el nivel de abstracción de datos que manejan y por sus propiedades estructu-rales, caracterizadas por su grado de acoplamiento, cohesión y densidad (ver ??).Efectivamente, los componentes de la infraestructura se caracterizan por su solidez yfuncionalidad, ya que están destinados a tareas estructurales en el sistema, cerca delas librerías de bajo nivel; por tanto, no son aptos para la programación de servicios ynecesitan capas de mediación para integrarse en el resto del Soporte. Desde el puntode vista de su agregación, los componentes de infraestructura estarán fuertementeacoplados, formando capas con una densidad ajustanda al grado de abstracción yprocesamiento de datos. Por su parte, los componentes de servicio deben ser muyadhesivos y acoplarse muy ligeramente a la plataforma de servicios, transportandolos recursos imprescindibles para desempeñar su función. Esto hace que los compo-nentes de servicio sean más ligeros, autónomos y selectivos, cerrando su visibilidaddel sistema a los puntos de anclaje y los elementos de la lógica que son de interéspara la función del servicio. Estas características se reflejan en el ancho de bandaexplotado por los componentes: mientras que los miembros de la arquitectura vana enviar muy poca señalización y un gran volumen de datos, los servicios generanmucha señalización y un volumen pequeño de datos de usuario.

Como buscamos un sistema que sea modular y escalable, la estructuración delsistema es necesaria no sólo para aplicar el diseño de componentes más adecuadoa las especificaciones de cada tarea, sino, fundamentalmente, para permitir el estu-dio del sistema a través de sus partes y para garantizar que todos los componentespuedan ser reemplazados o modificados sin afectar al resto del sistema. De forma

207


natural, se consigue esta separación al integrar en un mismo sistema distintas redesde dispositivos con funciones separadas, ya que partimos de una situación de aisla-miento fisico entre bloques. Sin embargo, la lógica del sistema debe articularse y seroperativa sobre esta organización de bloques, planos y protocolos. La solución a esteproblema se alcanza a partir de una mecla de la orientación a servicio y el paradigmaAmI en una topología de integración jerárquica - como la planteada por Eckl en [12]- de tal modo que, a partir la instalación de referencia, con la aplicación de unaWSN para la localización de nodos en movimiento (The BOX), podemos desarrollarun sistema sobre OSGi para conectar las capacidades de la WSN con dispositivosUPnP y poner estos recursos a disposición de los servicios, que son la interfaz con losusuarios del sistema. Siguiendo el esquema planteado, la arquitectura de integraciónpodría responder al esquema de la Figura 13.4:

Figura 13.4.: Esquema del Soporte Técnico a partir del modelo de Eckl

Desde el punto de vista de los medios en uso, la aplicación debe desarrollar funcionesque sean transversales, para conectar los dispositivos instalados en los distintosbloques y, al mismo tiempo, una solución que habilite el acceso a estos dispositivos através de una interfaz de gestión, de tal forma que, en el Soporte Técnico, el conceptogenérico de Infraestructura de Composición de Servicios se manifiesta comouna solución de integración que permite la coordinación de dispositivos heterogéneos.Para ilustrarlo, podemos ver un diagrama de integración de las tres arquitecturasde protocolo (ZigBee - OSGi - UPnP):En la imagen, se ha trazado en rojo el enlace que establecen los servicios del SoporteTécnico. Como vemos, crean un dominio de cooperación entre dispositivos remotos,descritos en formatos distintos, que se interconectan a través de la infraestructurade componentes dinámicos del servidor, siendo igualmente posible que el servidor secomporte como un dispositivo de servicio como proveedor, monitor o controladordel mismo, según el caso.La Infraestructura de Composición de Servicios elimina las diferencias tec-nológicas y facilia los medios para la integración y la expansión del sistema, pro-

208

13.1 Diseño

Figura 13.5.: Integración de tecnologías

veyendo un esquema consistente para la construcción del Soporte Técnico graciasa la disposición de la lógica contenida en la ontología. Así visto, este modelo dedesarrollo es el que mejor cumple con los Requisitos de plasticidad, expansión,interoperabilidad y manejo remoto propuestos para el Proyecto. Sin embar-go, no podemos aplicar directamente las técnicas de diseño de servicios, porque,aunque la metodología empleada es coherente con las metas generales de SOA (fle-xibilidad, valor de negocio, metas estratégicas, operatividad, servicios distribuidosy refinamiento progresivo), no es claramente una arquitectura orientada a servicio;en particular, el Soporte Técnico no está construido sobre una aplicación web, noestá pensado para integrarse en un modelo de negocio ni los servicios cumplen al100% los principios postulados (no son enteramente autónomos, hay partes que noson reutilizables, no todos son articulables y los extremos de servicio instalados enlas redes de captación o acción están fuertemente acoplados con su infraestructura,por lo que no pueden reconfigurarse sin modificar el programa), por lo tanto, debe-mos delimitar claramente las partes del Soporte que admiten un desarrollo SOA, laspartes que son anteriores y necesarias para dar soporte a la arquitectura SOA delSoporte y las zonas grises que hay entre ambas.

Unificando conceptos Hemos llegado a un modelo de sistema compuesto por unainfraestructura de integración y una plataforma abierta de servicios.La parte de integración ha sido concebida para adaptarse a un escenario de uso yun entorno de trabajo bien identificado, que hemos recogido en la ontología. Lainfraestructura responde en el plano inferior a la necesidad de coordinar y poneren comunicación a diferentes tecnologías de red, mientras que, en el plano superior,incorpora los elementos que facilitan al usuario la posibilidad de definir y controlarel comportamiento de una instalación artística interactiva. La segunda parte de estemodelo la constituye una plataforma de servicios: esta plataforma maneja las funcio-nalidades básicas de los dispositivos de las redes integradas y admite en el extremousuario diferentes comportamientos y métodos de control, de modo que, desde el

209


punto de vista del usuario, lo que establece la plataforma es un acceso remoto a losdispositivos instalados y un entorno para activar y configurar los “controladores” deestos dispositivos. La plataforma abierta de servicios no tiene por qué incluir todosestos controladores, tan sólo debe definir las interfaces en las que pueden conectar,por lo que aporta una lógica de datos, una lista de recursos, una interfaz de usuario,un protocolo de composición y un método de conexión, pero no cierra el SoporteTécnico a una aplicación específica, respondiendo así al objeto de crear una soluciónabierta a posibles usos y configuraciones y, al mismo tiempo, plantea un modelo deaplicación que aporta valor a todos los actores del escenario, abriendo la posibilidadal artista de introducir múltiples vías de interacción, capacidad para refinar el men-saje y reaprovechar su trabajo; para los operarios, aporta una interfaz de gestiónclara y sencilla, que puede manejarse sin necesidad de estar físicamente presente enla instalación; por último, para los desarrolladores, plantea un entorno que puedenexplotar para crear nuevos servicios sobre la misma instalación, sin necesidad depreocuparse por la programación de los niveles inferiores.Si volvemos al esquema de la Figura 13.4, la parte de integración del sistema co-rrespondería a los niveles de interfaz software entre redes, así como los puentes ycontroladores intermedios que sirven de enlace entre los dominios del Soporte. Losniveles de Plataforma y Servicios del Servidor y los Dispositivos embebidos de lasRedes integradas, por su parte, formarían la plataforma de servicios. Este esquemapuede darnos una idea de la complejidad de ambas partes y de la importancia capitalde una lógica unificada para hacer posible la coordinación entre componentes.Para finalizar esta sección, recuperamos los Casos de Uso para clasificarlos conformea su ubicación en el modelo de aplicación presentado, indicando finalmente quéentidades de la ontología participan en su desarrollo. Volveremos a esta informaciónmás adelante, cuando finalicemos la descripción de la solución con la Especificaciónde Servicios.

210

13.1 Diseño

Caso Parte del Sistema Bloquesimplicados

Entidadesparticipantes

HabilitarSoporte Técnico

AG WSN, SVR, AV,UI

INSTALACIÓN

Iniciar Sistema AG WSN, SVR, AV,UI

Equipos

Localizar alVisitante

PAS WSN, SVR Visitante, Cubo de Luz,Gestor de Servicios

Controlar elContenido

PAS WSN, SVR Visitante, Cubo de Luz,Gestor de Servicios

Definir Modos deControl

PAS SVR, WSN, AV Cubo de Luz, Proyector,Gestor de Servicios

Reproducir elMensaje

PAS SVR, WSN, AV Servidor de Contenidos,Cubo de Luz, Proyector

ControlarArtefactos

PAS WSN, AV Cubo de Luz,Proyector, Visitante

DefinirReacciones

PAS SVR, UI Servidor

HabilitarInterfaz Remota

AG + PAS UI, SVR Línea de comandos,Herramienta de red


PAS SVR Servidor

Habilitar Ajustede Módulos

AG + PAS SVR Servidor

Cuadro 13.14.: Ubicación de los Casos de Uso en la aplicación

211


13.1.2.3. Profile de aplicación

El Profile contiene todas las clases que participan en la construcción de la funcio-nalidad de alto nivel del Soporte. Actua como patrón para la comunicación entredominios: en última instancia, todas las capacidades y recursos intercambiados porlos componentes de servicio se expresan en elementos de estas clases. Al mismo tiem-po, las clases del Profile sirven como contenedores para las entidades clasificadas enla ontología, garantizando así su aplicación en el diseño en las interfaces de aplica-ción y la validez del modelo ontológico sobre todos los componentes del sistema queutilicen estas interfaces. A todos los efectos, el Profile establece el dominio lógico dela aplicación Soporte.

Figura 13.6.: Esquema raíz del Profile de aplicación

De la práctica ZigBee, hemos rescatado en el esquema Figura 13.6 las clases nuclea-res que integran el Profile. Deben formar parte del Profile todos los EndPoint, queidentifican localmente a los objetos de aplicación y sirven como puertos de comuni-cación para los servicios. El Profile también define todos los posibles Atributos, queson contenedores establecidos por la aplicación para uniformar la representación dedatos y se organizan dentro de los Clusters, que, además de servir como clasificado-res de Atributos, identifican a las funciones accesibles a través del EndPoint. Aunqueestos conceptos son originarios de ZigBee, pueden trasladarse fácilmente a las demástecnologías del Soporte, tanto en el caso de OSGi (su implementación en Java esinmediata a partir del esquema) como en el caso de UPnP (notar que las clases

212

13.1 Diseño

del esquema son abstractas, por lo que admiten una especialización en la que estosconceptos se adapten a la arquitectura UPnP).El Soporte Técnico es el resultado de implementar el Profile en una arquitecturamodular que responde a la instalación de referencia. El Profile se desprende de laontología, que es, a su vez, una abstracción de un modelo de Instalación en el que sepueden identificar los Bloques de la arquitectura. Como vemos, en última instancia,no podemos desligar el modelo de datos del modelo físico, pues están imbricados enla lógica de la aplicación.

Figura 13.7.: Modelo lógico del sistema

A partir de este equilibrio, vamos a recorrer las dos mitades del esquema de laFigura 13.7, unidas por la asociación en el Soporte Técnico. Si vemos la mitad su-perior de este esquema, tenemos las clases que sirven para la construcción de lainfraestructura. El Soporte Técnico va a modelarse a partir de serie de Bloques,que definen la extensión material de la Instalación. Cada uno de estos Bloques res-ponde a un esquema físico (contenido en un Dominio), de tal forma que un Bloque- visto como Dominio - surge de la agregación de Equipos en un medio físico. Porlas peculiaridades de la instalación de referencia, casi siempre vamos a hablar in-distintamente de Dominio o Bloque, ya que todos los Equipos desplegados en unmedio van a estar conectados y coordinados entre sí, pero, en general, la vecindadno obliga ni a a la conexión ni a la agregación, de ahí que el modelo trate de formaindependiente los conceptos de Red y Dominio, puesto que un único bloque puede

213


estar repartido por varios medios físicos que deben integrarse a bajo nivel o, alter-nativamente, desplegarse sobre un único medio pero en Redes que no interactúanentre sí, si no es a través del Nodo Central. Salvando este nivel, los conceptos Nodoy Equipo son complementarios, de forma que un Nodo es una caracterización de unEquipo en una Red y un Equipo es un contenedor físico para una identidad de Reddentro de un Dominio. De nuevo, esto no implica que el número de Nodos y Equiposcoincidan, ya que un mismo Equipo puede actuar como Nodo en distintas Redes:esto lo vemos, por ejemplo, en el bloque WSN del sistema, que está constituido porun único dominio que habla dos protocolos - ZigBee hacia el interior de la red yRS232 hacia el Servidor - caracterizado por la función de Pasarela del equipo en lafrontera entre ambos. Como ejemplo del caso contrario: el bloque AV está partidoen dos dominios que usan el mismo estándar UPnP, sólo que una parte del bloqueestá alojada dentro del Servidor y el resto se encuentra distribuido. Las diferenciasarquitectónicas entre ambas soluciones (WSN, AV) obedecen al esquema de inte-gración de la Figura 13.4, donde se evidencia que ZigBee participa sólo como redsubsidiaria en el Soporte, mientras que UPnP, aunque tiene una función similar (enlos efectos audiovisuales), sirve también como recurso para la interfaz de conexióna dispositivos remotos por IP.

Volviendo al esquema, la mitad inferior contiene las Clases que soportan la plata-forma de servicios. Como vemos, el modelo de aplicación (contenido en el Profile)se aplica directamente en la asignación de Servicios a los Nodos, a través de inter-faces (denominadas EndPoint) que éste habilita. El concepto clave en el desplieguede Servicios es el de Dispositivo, que no responde directamente a una entidad físicadel sistema, sino a una asociación funcional de las capacidades y recursos necesariospara el desempeño de un servicio.

Las capacidades de un Nodo se definen a través de Descriptores. Partiendo delmodelo de aplicación ZigBee, se proponen cuatro tipos de Descriptores, de entrelos cuales destacan el Descriptor de Usuario (que recoge las Características ge-nerales del Nodo) y el Descriptor Simple, que es la clase que define en términosdel Profile las prestaciones y capacidades del Equipo que pueden manejarse a travésde un EndPoint. El componente que habilita un Servicio, reglado por un DescriptorSimple, a través de un EndPoint, se denomina Dispositivo. El Descriptor Simple,asociado a un EndPoint de un Nodo, actúa como controlador del Servicio y sirve en laRed para conectar con otros Dispositivos dentro del mismo Servicio. En principio (ysalvo los recursos reservados), un Dispositivo puede instalarse en cualquier EndPoint,pero los Servicios que puede activar están limitados por los Clusters de entrada ysalida del Descriptor, que, como hemos dicho, expresan modos de función com-patibles con las capacidades del Equipo. Aplicando esta idea, podemos generar lasespecificaciones de cada Servicio de forma secilla, en términos de Clusters registradospor el Descriptor Simple de un Dispositivo. Es una idea muy intuitiva: una persianade tambor no admite giro de lamas, una bombilla no puede reproducir una película,pero una persiana o una bombilla sí pueden regularse a una posición fija; en general,un Equipo puede instalar los Dispositivos cuyos Descriptores sean coherentes con

214

13.1 Diseño

los Clusters de entrada / salida que incorpora. Esta simple regla es la base del diseñode los Dispositivos, ya que cada Dispositivo va a ser un componente de Servicio activoen un Endpoint, por lo que cada Nodo tendrá que incluir los Descriptores adecua-dos a los Servicios que vaya a implementar y, a bajo nivel, tendrá que incluir loscomponentes hardware necesarios para cubrir todas las funcionalidades deseadas.

Con la definición de los Roles, se completa la información contenida del Profile yla descripción de la aplicación. Los Roles son perfiles de Nodo, conjugando las ca-racterísticas generales (función de red, configuración hardware, autonomía) y losServicios (EndPoint / SimpleDescriptor) que incorpora. Con el conocimiento delos Descriptores y la confección de los Clusters (Atributos), la identificación de losRoles aporta todos los datos necesarios el despliegue de Servicios, unificando el usode los EndPoint para cada aplicación, casando los Descriptores Simples con losdiferentes Roles en cada servicio (según el modelo, serán pares del servicio o pro-ductores / consumidores) y estableciendo los requerimientos de los Equipos, tantoa nivel hardware (alcance de transmisión, alimentación, consumo, robustez, dimen-siones, bus de datos, funcionalidad) como software (memoria, tiempo ciclo, anchode banda, tamaño de buffers, arquitectura del sistema operativo).

La aplicación de este modelo será intensiva en el diseño de los Dispositivos; volvere-mos una y otra vez sobre estas entidades cuando definamos los Servicios. Por ahora,nos basta con captar la noción de que el Profile es la base para identificar las distin-tas configuraciones de los Equipos del sistema (a través de los denominados Roles)y para definir los Servicios (en términos de EndPoints, Clusters y Atributos).

13.1.2.4. Lógica de dispositivos

Si recordamos la Figura 4.12, el Profile de la aplicación es sólo uno de los productosde modelado que componen el Diseño del Soporte Técnico. Sin duda, se trata deun elemento central, que unifica la lógica de los distintos Dominios y establece unlenguaje común a todos los componentes del sistema, pero no es más que un artefac-to, que necesita medios reales para ser efectivo. Conforme nos vayamos alejando delentorno teórico para acercarnos a los objetos del dominio lógico, veremos cómo lasClases del Profile van siendo referenciadas a través de clases herederas, constituyendoel núcleo de los artefactos sobre los que vamos a construir realmente la aplicación.El primer paso para acercarnos a este objetivo pasa por completar la descripciónteórica del Soporte, a través de los Dispositivos que participan en el sistema.

Aunque el concepto de Dispositivo no admite un modelado como Clase en la lógicade la aplicación, hemos dicho que su importancia es fundamental a la hora de dise-ñar todo el sistema, ya que representa una relación activa entre un componente deaplicación y un Servicio que se está ofreciendo a la Red a través de un EndPoint. Enesta relación, quedan conectados los medios del Equipo (accesibles a través del End-Point) con la especificación del Servicio (reflejada en el Descriptor); internamente,

215


la lógica de dispositivo garantiza la coherencia del sistema con el Profile, lo que esequivalente a decir con la ontología.En la Figura 13.8, se desarrolla la estructura de clases en torno a los Dispositivos,ilustrando cómo se articulan la lógica de aplicación (contenida en la representa-ción de datos y la identificación de funciones del Profile) y la arquitectura, que seconstruye en los Componentes y se realiza a través de los EndPoints. Como vemos,internamente un Descriptor Simple es una relación de Clusters de entrada y salidapara un Dispositivo. Los Clusters de salida identifican funciones que se desarrollanhacia la red, esto es, serán clientes o consumidoras de un servicio remoto; de formacomplementaria, los Clusters de entrada apuntan a servicios ofrecidos por el Dispo-sitivo a la red. En la WSN, tendremos Dispositivos que van a proveer informaciónde localización y dispositivos que la consumen; como podemos intuir, la composi-ción de sus Descriptores será complementaria, de tal forma que las listas de salidade los dispositivos consumidores casan con las listas de entrada de los dispositivosproveedores.La idea de complementariedad de Dispositivos es fundamental para la lógica de Ser-vicio, ya que los Servicios son, en última instancia, mecanismos de intercambio entreun componente que busca una funcionalidad y un componente que está ofreciendoesa funcionalidad a través de la Red. Este planteamiento no establece a priori unaprevalencia ni una jerarquía entre los actores del escenario, sino una relación deutilidad, que puede resolverse de distintas formas, en función del modelo de aplica-ción seguido. Es igual de factible controlar tres luces desde un mismo pulsador quecontrolar una luz desde tres pulsadores, lo que no podemos hacer es controlar el dialde la radio con un regulador de luz. Al menos, a priori.Continuando con el diagrama, hemos recorrido la parte externa - asociada al Profile- para descubrir su utilidad en la especificación de los contratos de Servicio (partien-do de los Descriptores Simples).La parte interior de los Dispositivos se desarrollaen la columna izquierda del esquema y nos conduce directamente a la arquitecturaorientada a servicio. Sintéticamente, un EndPoint será un componente del nivel deaplicación con permisos habilitados para invocar métodos de comunicación (tantodel plano de datos de usuario como del plano de gestión - señalización). Los End-Points pertenecen a la torre de protocolo del Nodo y son parcialmente accesibles parael programa de usuario, por lo que son objetos completamente seguros: su manejoestá reglado por los Clusters de entrada y salida del Descriptor registrado en dichoEndPoint. Se explica así la triple sindicación del EndPoint con la lógica de dispo-sitivo: para la aplicación embebida en los Nodos, el EndPoint aporta la interfaz deexplotación del protocolo una vez registrado el Descriptor Simple. De cara a lared, el modelo de servicio no obliga al establecimiento de sesiones, pero, de algúnmodo, la aplicación necesita obtener información para direccionar sus peticiones,justificando así la necesidad de que la interfaz EndPoint medie en el establecimien-to de conexión y en la búsqueda de Nodos y Dispositivos. Por último, la lógica deDispositivo impone que la arquitectura interna de los Servicios sea consistente con larepresentación de datos del Profile, limitando las variables de representación de los

216

13.1 Diseño

estados del Componente de Servicio a los Atributos de los Clusters invocados pordicho Servicio (que, a su vez, sólo serán válidos si pertenecen a la lista de entrada osalida - según el método - del Dispositivo).Con la lógica de dispositivo, las entidades del Profile adquiren consistencia y cohe-sión. Los Dispositivos van a definirse como colecciones de Clusters gobernados porun mismo componente de aplicación que toma el control de un EndPoint. Aunqueno podemos identificar el Servicio con el Dispositivo - porque, en realidad, un mismoServicio puede desplegarse en cualquier EndPoint reconocido por el Profile para ins-talar un SimpleDescriptor (en este sentido, un EndPoint puede ser entendido comoun “puerto” en la jerarquía IP) - el hecho de que un Nodo esté ofreciendo un Serviciodenota unas características del Nodo y la disponibilidad de los Clusters de entrada ysalida asociados al servicio. Tampoco podemos tomar el Componente de aplicaciónpor el Dispositivo - porque el modelo admite que un Componente necesite de otrospara explotar un EndPoint - y, sin embargo, la activación de un SimpleDescriptorno es efectiva si el Nodo no cuenta con los métodos para desarrollar todas las funcio-nes de sus Clusters y, en paralelo, un Componente no sirve de nada en una aplicacióndistribuida si no publica sus capacidades con un Descriptor acorde al Profile deaplicación.

Figura 13.8.: Lógica de dispositivo

La lógica de dispositivo refleja una noción que intuitivamente asociamos a las aplica-ciones sobre redes de sensores y actuadores, por lo que resulta una herramienta muy

217


útil para identificar los contratos de Servicio y los requerimientos de los Equipos ne-cesarios para construir la aplicación de los bloques de Red del Soporte. Para aplicaresta técnica, sólo tenemos que partir de los Casos de Uso y la relación de Equiposestablecida en la ontología. Estos Equipos van a definir los Roles del Profile, de talforma que, como los Dispositivos son una instancia de un Rol para un Servicio concre-to, podemos identificar sin ambigüedad un Equipo por su identidad como Nodo y porsu Rol. La diferenciación entre Dispositivo y Nodo es importante porque se respeta enla arquitectura de la aplicación (hecho que queda reflejado en el diagrama anterior,en la realización en un EndPoint de un Componente de Aplicación, denotando asíun diseño interno separado por Servicios), pero, a escala global, podemos abarcartoda la lógica de dispositivos sólo con describir los posibles Roles de los Equipos enel sistema. Los desarrollamos a continuación:

1. Visitante: Un dispositivo con rol visitante se conectará automáticamente ala red por donde pueda y establecerá un diálogo continuado con la entidadRouter más cercana a su ubicación. En caso de que este diálogo se vea inte-rrumpido o la calidad del enlace caiga por debajo de un umbral, esperará untiempo y se reiniciará, comenzando de nuevo. Este diálogo sirve para renovarlos temporizadores internos de los Routers, que establecen el camino físico delmensaje hacia el resto de la red; por otra, el mensaje de respuesta llega demanera transparente hasta el visitante y aporta información sobre la calidaddel enlace, que sirve como base para garantizar que los visitantes están siem-pre conectados al Router más cercano(movilidad). Esta capacidad es la que dionombre originalmente a la función de traspaso, ya que, aunque sea un procedi-miento rústico, se está implementado un HandOver de los equipos terminalesdentro de la red WSN.Además del comportamiento como Visitante dentro de la WSN, el rol incorporaotras funciones de gestión (ahorro de energía, sincronización) y participa en laplataforma de servicios, implementando las siguientes funciones:a) Estimación de posición por mínimos cuadrados de las distancias LQi.b) Envío de datos del proceso de estimación al servidor y flexibilidad para

actualizar su posición por indicación externa.c) Solicitud de mapeo de posición. Registro / salida de zonas de la instala-

ción.d) Presentación de credenciales (preferencias del dispositivo) para la reali-

zación de los efectos interactivos.e) Respuesta a cualquier solicitud relacionada con la generación de efectos.

2. Pasarela: Los dispositivos pasarela mantienen el enlace con la aplicación degestión Servidor y, por lo tanto, residen en la frontera entre Bloques. La tareade una pasarela es sencilla pero crítica: debe abrir un canal de comunicaciónbidireccional por donde recibir mensajes de los dispositivos de red y adaptarlospara que puedan ser transmitidos por el enlace con el equipo Servidor. En el

218

13.1 Diseño

caso WSN, el enlace se implementa por una vía RS232 entre la UART delmódulo ZigBee que hace de pasarela y un puerto USB del PC servidor. Enla topología WSN, todos los nodos pueden acceder al nodo Gateway y éstepuede retransmitir un mensaje del Servidor hacia cualquier nodo de la red,aprovechando la topología para minimizar el número de pasos que debe dar elmensaje hasta su destinatario. Por su desempeño, los dispositivos programadoscomo pasarela se desentienden de otras tareas y servicios, salvo las funcioneselementales para mantener la comunicación entre Dominios, que se resumen endos:

a) Servicio de ajuste de hora.b) Adaptación:

1) Túnel de datos (Z2O). En realidad, supone toda una capa de pro-tocolo que permite la integración del Servidor como un nodo más dela WSN a través de la pasarela, haciendo posible la comunicaciónextremo a extremo de forma transparente a la red.

2) La adaptación entre el dominio Servidor y la red AV sólo necesitainvocar los métodos de la librería que media entre la arquitectura in-terna del Servidor (OSGi) y la arquitectura UPnP de la red. Además,la topología de la red UPnP es un bus, por lo que la adaptación nose apoya en la construcción de túneles, sino en la activación de lospuertos TCP adecuados para el diálogo entre Nodos UPnP.

3. Router: Un dispositivo Router (o Beacon) tiene capacidad para aceptar cone-xiones entrantes y por tanto desempeña una función importante en el desplie-gue y el sostenimiento de la red. Se definen como nodos estáticos, tienen unaposición fija y conocida, por lo que tienen también protagonismo en las tareasde movilidad, localización y definición de las zonas de escena de la instalación,lo que los convierte en dispositivos cruciales para el desarrollo de los serviciosdel Soporte. De entre sus muchas funciones de servicio, podemos destacar:

a) Gestión de zonas escénicas, programación de comportamientos y secuen-cias.

b) Calibrado LQi, diálogo LQi con Visitantes.c) Coordinación y reproducción de efectos escénico, comportándose como

maestros o esclavos dentro de una zona de escena activa para ejecutaruna secuencia programada de comportamientos o efectos a través de loselementos de acción que tienen instalados (luces, en este caso).

La gran variedad de papeles que desempeñan los Routers en la Plataforma deServicios hace que muchas veces nos refiramos a ellos por su papel específicoen el servicio, de modo que, en vez de Routers, hablaremos de Cubos de Luz(LightCube), Guardas de Zona, Director o Actor de Escena.

219


4. SuperRouter o Maestro: La función principal del SuperRouter es la de mante-ner la red WSN y controlar las etapas de despliegue de dispositivos. El controlde despliegue es fundamental para que los servicios cuenten con la infraestruc-tura necesaria para ser efectivos y para que la red mantenga su consistenciaante cualquier eventualidad. El SuperRouter sólo admite conexiones de Routersy de la Pasarela, de modo que permanece oculto a los Visitantes y sus funcionesestán programadas para no responder a ninguna solicitud de un dispositivoVisitante.

En resumen, las funciones que ejerce este dispositivo en la aplicación son lassiguientes:

a) Tareas de establecimiento y mantenimiento “core” de la WSN, incluyendotopología, enrutamiento y asignación de direcciones (ZigBee blueprint).

b) Control de despliegue de red (Netstage) como agente local de control enla WSN de la función de arranque del sistema.

c) Difusión de reloj como parte del servicio de ajuste horario.

d) Respuesta a mensajes de consistencia de red, sincronización y calibradode los dispositivos Beacon y Gateway.

5. Servidor: El servidor no cumple un papel como tal en ninguno de los serviciosdel Soporte, pero sí que contiene multitud de componentes en su arquitecturaque se comportan, a todos los efectos, como un dispositivo más. A todos es-tos dispositivos que participan en los servicios distribuidos del Soporte se lesdenomina Servidor, cuando no reciben un nombre más específico.

Desde el punto de vista de la aplicación de gestión, el servidor es el agen-te principal del sistema, siendo la única entidad que debe permanecer activamientras el Soporte Técnico se encuentre operativo. Tiene un papel fundamen-tal en el despliegue y configuración de servicios, acapara casi en su totalidad lacomunicación con el usuario y actúa como integrador de las diferentes redes,pero, además de esto, aloja en sus capas superiores a los agentes que conec-tan los servicios con la interfaz de usuario, los componentes que almacenany distribuyen la configuración de los dispositivos remotos y los dispositivosde servicio que logran la coordinación entre dispositivos de bloques distintos,entre los que podemos destacar:

a) El motor de seguimiento de visitantes, que puede refinar la estimación dela posición recibida desde los dispositivos remotos y cambiar la configu-ración de servicio si cambian las condiciones de calibrado de los Beacon.

b) Un Director, que puede actuar subsidiariamente cuando las escenas re-quieren la coordinación entre dispositivos de luz y vídeo.

c) El componente que define y controla la zonificación de la instalación.

d) El reloj de referencia del sistema.

220

13.1 Diseño

e) El punto de control de la reproducción vídeo.6. Proyector: Se denomina así al nodo UPnP recogido en la ontología como el re-

productor de medios audiovisuales. Según la topología, podrá estar compuestopor un MediaServer y un MediaRenderer locales (contenido distribuido en lared) que son manejados por el Servidor, o sólo por la parte MediaRenderer,conectada a través del ControlPoint del servidor con un proveedor remoto dedatos.Físicamente, un dispositivo Proyector está compuesto por un equipo de proyec-ción que, o bien puede conectarse directamente a una red UPnP, o bien recibela señal vídeo de otro equipo en el que se esté ejecutando la aplicación de lopermita. Esta configuración permite gran libertad a los creativos para gene-rar los efectos vídeos con los mínimos recursos necesarios y de la forma máscómoda para sus propios hábitos. En la instalación The BOX, por ejemplo,se utilizaron portátiles con una aplicación de vídeo distribuido por streaming;en el Soporte Técnico, podríamos aplicar el mismo modelo sin necesidad demodificar la lógica del sistema, ya que la resolución de la comunicación entrelos componentes del dispositivo se resuelve internamente en el dominio UPnPy, por tanto, de forma transpartente al resto de la aplicación (al menos, en teo-ría, ya que no podemos descartar que una configuración más compleja tengaun efecto en el rendimiento global).

Bloques del Sistema La relación anterior, nos permite ilustrar los Bloques delSoporte Técnico por medio de los Dispositivos conectados dentro del Bloque y losenlaces que se establecen entre ellos. Esta definición se corresponde tanto a nivel deEquipos como a nivel de Arquitectura software, ya que la organización en Bloques delsistema es vertical y parte de las Redes desplegadas y las soluciones de integraciónentre los distintos Dominios.En la Figura 13.9, vemos perfectamente identificados los Equipos, los Dispositivos ylos Dominios de ejecución y comunicación. Se han representado otros componentesde la aplicación que no responden a la lógica de Dispositivo, que participan en lainfraestructura del sistema o desempeñan funciones auxiliares para los componentesde servicio. También, se han marcado con raya discontinua los Bloques distribuidosdel sistema (WSN, AV); los demás Bloques (SRV, UI), podemos encontrarlos embebidosdentro de la Estación PC.Aunque la programación de las funciones de la lógica de Dispositivos correspondetan sólo a la parte más superficial de la arquitectura de red, la relación anterioraporta suficiente información como para identificar los Roles que van a desempeñarlos Nodos en la WSN y la red AV, cómo se va a establecer la conexión con el Servidor yla posición que va a ocupar este nodo central en la topología de las Redes del sistema.Gracias a los Roles, tenemos también una relación de las funciones estructurales y lastareas auxiliares que desempeña cada Dispositivo y, con ello, hemos empezado aúnsin saberlo a hablar de Servicios. Todos estos elementos quedarán ubicados cuando

221


Figura 13.9.: Esquema de despliegue de los dispositivos y plugins

terminemos el capítulo presentando la lógica de Servicio, pero antes tenemos queahondar en la construcción de los mecanismos de comunicación que hacen posiblela conexión entre Dispositivos instalados en Equipos de Bloques distintos.

13.1.3. Protocolo de comunicación

La necesidad de un protocolo de comunicación es inherente a la integración de sis-temas heterogéneos que plantea el Soporte Técnico. Dado que la Instalación va adesplegar una red de sensores y actuadores separada de la red de efectos multimedia,el diseño del Soporte incluye la especificación de los mecanismos que van a hacerposible el intercambio entre Nodos. La solución a este problema, sin embargo, no vaa ser homogénea para todos los Bloques, sino que vamos a aplicar un diseño dondeel Servidor actúe como Nodo centralizador de fotma subsidiaria a los Bloques. Elprincipal interés del Soporte no es canalizar todas las comunicaciones a través delServidor, sino establecer eficazmente canales de diálogo entre Dispositivos; por tanto,la elección del Servidor como Nodo de paso en la comunicación dependerá de dosfactores: por una parte, la capacidad de los Nodos remotos para integrarse con elresto del Soporte y, por otra, el grado de participación de los Dispositivos del Servidoren el diálogo.

222

13.1 Diseño

Para diseñar un mecanismo de intercambio que sea común a las Redes del Soporte,necesitamos partir de un modelo de mensaje reducido al mínimo común de todos losprotocolos aplicados. Podemos ver este modelo en la siguiente imagen:

Figura 13.10.: Modelo de mensaje

Debemos entender la Figura 13.10 como un modelo de trabajo con los elementos deinterés para el diseño de la aplicación Soporte. Claramente, este esquema debe partirdel conocimiento previo de los Protocolos de Red, de modo que el desarrollo dela aplicación respete los procedimientos de instalación, implantación y desplieguepropios de cada uno de ellos. Una vez hecha esta prevención, el modelo de mensajecorresponde a la explotación por parte del programa de usuario, para el que sóloes relevante el protocolo en tanto que es necesario para conducir los Mensajes, en elformato adecuado, hasta sus destinatarios. Sólo en el caso de que el Protocolo noenvuelva completamente el tratamiento interno de los Mensajes sería responsabilidadde la infraestructura de aplicación garantizar la formación de las tramas para eltransporte de Mensajes. Por esto mismo, la aplicación generada con el Profile sóloaccede al Protocolo a través de los métodos generales de la API de comunicación.El modelo de Mensaje reduce el intercambio a dos mecanismos: uno de acción -denominado “Comando”- y otro pasivo - definido como “Respuesta”. Ambos realizanel mismo objeto “Mensaje”, por lo que ambos tendrán la misma estructura de tramae invocarán los mismos métodos del Protocolo, pero tienen la peculiaridad de queun Comando es una comunicación de una Acción (que podría corresponder al envíode una señal, una orden o consigna, el establecimiento de una conexión o parte deuna secuencia de diálogo) mientras que la Respuesta es una comunicación producidacomo consecuencia de una Acción previa.Los Servicios van a explotar el modelo anterior de comunicación tanto en el inter-

223


cambio de señalización y datos de gestión como en el envío de datos de usuario. Enel plano de gestión, el modelo Comando - Respuesta servirá para estructurar todoslos posibles diálogos entre partes del Servicio (Dispositivos), por lo que tendremosuna gran variedad de Comandos y diferentes secuencias, en función del acción delServicio y los Efectos que se den para un estado de servicio determinado. En el planode datos, la diversidad de Comandos se limitará a los diferentes contenedores de da-tos que habilite el protocolo y las Respuestas serán los mecanismos de asentimientoy conservación del enlace que utilice el Nodo receptor.Para concluir, el modelo de mensaje establece que cada Comando - Respuesta vayaencapsulado dentro de una trama distinta. De nuevo, esta condición se aplica sinafectar al intercambio de datos, ya que, naturalmente, los datos de usuario demasiadograndes se trocean y envían en paquetes ordenados, por lo que el modelo puedeadaptarse a estos mecanismos sin dificultad donde sea necesario. Este criterio, sinembargo, sirve para alcanzar un diseño de la capa de señalización que sea más eficazy ligero, reservando los mínimos recursos y acortando los tiempos de establecimientopara faciltar la respuesta global del sistema cercana al tiempo real.

13.1.3.1. Dimensionamiento

Para el dimensionamiento del protocolo, vamos a partir de las estructuras y fun-ciones de los protocolos implementados en el Soporte que resulten críticas por sulimitación de recursos para el resto del sistema. Tomaremos este límite inferior comodenominador común para diseñar un protocolo de intercambio que sea fácilmentetrasladable a los protocolos más potentes, de modo que, si las especificaciones deservicio no ocupan todos los recursos de la Red en el peor caso, quedará garantizadala capacidad del sistema en el resto.Por las características de ZigBee y UPnP, el primero resulta crítico para el dimensio-namiento por sus prestaciones de baja latencia de datos y prioridad de la robustezfrente a la calidad de las comunicaciones. Además, la mayoría de los Servicios con-sideran al Servidor como un Nodo más dentro de la WSN o necesitan del Servidorpara coordinar los comportamientos en los Bloques distribuidos, siendo, en amboscasos, mucho más importante para el desarrollo del Soporte el tramo de integraciónZigBee que la integración mulimedia sobre UPnP, fundamentalmente, porque losDispositivos de captación de información están en la WSN y la interfaz de usua-rio, aunque se comunica por UPnP con el Servidor, resuelve la integración de formatransparente a la aplicación. Por todos estos motivos, el dimensionamiento parte delas especificaciones de ZigBee para desarrollar el modelo de intercambio común a laaplicación.En la siguiente imagen, tenemos en orden inverso los formatos de trama de las capasde aplicación y red del estándar ZigBee y, justo debajo, el formato de las PDU802.15.4.

224

13.1 Diseño

Figura 13.11.: Formatos de trama ZigBee

En el siguiente recuadro, tenemos la definición del método de envío implementadopor la pila de protocolo de los equipos Jennic JN5139, utilizados en la construcciónde la prueba del Proyecto. Podemos ver que la llamada al método de envío incorporalos parámetros de cabera para generar una trama del nivel AF de ZigBee, con algunaspeculiaridades: el tamaño del identificador de Cluster es de 8 bits (el estándar deja 2bytes para el Cluster), no hay dirección de Grupo y la llamada incluye parámetros queno forman parte de la cabecera. Estos parámetros sirven para configurar el modode envío del mensaje que, internamente, conforman la cabecera del nivel de red.Para el dimensionamiento, el más importante de estos parámetros es el denominadoeFrameType, que identifica la estructura de la APS Payload. Las diferencias con elestándar se explican por la versión de ZigBee implementada en el SDK del fabricante,que corresponde a la versión ZigBee 2003, anterior a ZigBee Pro 2007. A efectosprácticos, no supone una limitación grave para el Soporte, aunque perdemos lacapacidad de crear dominios de difusión dentro de una misma red por medio deetiquetas de grupo (que sería el equivalente a VLAN en IP).PUBLIC Stack_Status_e afdeDataRequest ( APS_Addrmode_e eAddrMode ,

uint16 u16AddrDst ,uint8 u8DstEP ,uint8 u8SrcEP ,uint16 u16ProfileID ,uint8 u8ClusterID ,AF_Frametype_e eFrameType ,uint8 u8TransCount ,AF_Transaction_s * pauTransactions ,APS_TxOptions_e eTxOptions ,NWK_DiscoverRoute_e eDiscoverRoute ,

225


uint8 u8RadiusCounter );

La versión ZigBee implementada en la librería del SDK de prueba define dos estruc-turas para la Payload APS: los denominados “mensajes” (MSG) y las transaccionesde pares etiqueta - valor (KVP3). Una payload tipo MSG es un contenedor genéricode bytes y sólo adjunta a la información del usuario un indicador del tamaño delmensaje. Este tipo de tramas no tiene una utilidad específica en ZigBee: sirven paratransportar datos con la mínima cabecera posible. Por su parte, los mensajes KVPpretenden ser una adaptación de XML a las características ZigBee; en una transac-ción KVP, se incluye una cabecera propia para dentificar el Atributo destino y elcódigo de Comando que caracterizan al mensaje. En el fragmento siguiente, vemoscómo la librería las define como dos clases dentro de una misma unión (uFrame),que constituye el cuerpo de las transacciones del nivel AF.typedef struct{

uint8 u8SequenceNum ;union{

AF_Msg_Transaction_s sMsg;AF_Kvp_Transaction_s sKvp;

} uFrame ;} AF_Transaction_s ;

En el siguiente listado, tenemos la definición de ambas estructuras complementarias.Los mensajes KVP sólo puede transportar un tipo de datos compatible con los tiposdefinidos por el estándar ZigBee, que son los identificados en la unión de tipos dentrodel campo uAttributeData. Los demás parámetros de la transacción correspondena la cabecera interna del mensaje KVP, incluyendo el código de Atributo (2bytes), elcódigo de Comando (enumerado de 1 byte), el tipo de atributo (para comprobar lacoherencia de los datos) y un código de control de error para el diálogo de confir-mación con el destinatario. En términos de capacidad, la diferencia entre los KVP ylos MSG es de 5 bytes. La característica distintiva de los KVP es que, mientras los MSGson de propósito general, éstos van destinados a un Atributo e identifican perfecta-mente la operación relacionada por medio de los Comandos. Desde el punto de vistadel diseño, resulta mucho más sencillo construir un protocolo para la plataforma deservicios a partir de mensajes KVP, como trataremos de justificar a continuación.

typedef struct{

uint8 u8TransactionDataLen ;uint8 au8TransactionData [ afcMaxMsgPayloadSize ];

} AF_Msg_Transaction_s ;

typedef struct{

AF_KvpAttributeDataType_e eAttributeDataType ;AF_KvpCommandTypeID_e eCommandTypeID ;uint16 u16AttributeID ;AF_ErrorCode_e eErrorCode ;

3Del inglés Key Value Pair

226

13.1 Diseño

union{

uint8 UnsignedInt8 ;int8 SignedInt8 ;uint16 UnsignedInt16 ;int16 SignedInt16 ;uint16 SemiPrecision ;uint32 AbsoluteTime ;uint32 RelativeTime ;AF_Kvp_AttributeData_String_s CharacterString ;AF_Kvp_AttributeData_String_s OctetString ;

} uAttributeData ;} AF_Kvp_Transaction_s ;

Asumiendo un método de transporte basado en mensajes KVP, el dimensionamientode los mensajes vendrá determinado, en suma, por la capacidad de la transacciónKVP más grande, que es el resultado de restar al tamaño de una trama ZigBee todaslas cabeceras y taras que pueda añadir. Tenemos el desarrollo de este cálculo en elsiguiente recuadro:

Algoritmo 13.1 Capacidad útil de una transacción KVPafcMaxKvpStringAttrPayloadSize = afMaxPayload - KvpOverHead = [0] - 1 B

[0]: afMaxPayload = afcMaxTransactionFieldSize - afcMaxOverhead = [1] -[2][1]: afMaxTransactionFieldSize = apsMaxPayloadSize - afcMaxFrameOverHead =[3] - [4][2]: afcMaxOverhead = 5 B[3]: apsMaxPayloadSize = nwkMaxPayloadSize - apsMaxFrameOverHead = [5] -[6][4]: afcMaxFrameOverHead = 1 B[5]: nwkMaxPayloadSize = macMaxPayloadSize - nwkMinHeader = [7] - [8][6]: apsMaxFrameOverHead = 6 B[7]: macMaxPayloadSize = MAC_MAX_PHY_PKT_SIZE - MAC_MAX_DATA_OVERHEAD =127 - 25 = 102 B[8]: nwkMinHeader = 8 B

afcMaxKvpStringAttrPayloadSize = 81 Bytes

La conclusión que sigue al cálculo anterior es evidente: con un ancho de banda de250Kbps, una capacidad útil de 81 Bytes por transacción y una tara del 36,22%,el principal uso de la WSN en el Soporte Técnico debe ser el envío de señalizaciónentre servicios. ZigBee no está pensado para establecer un enlace de comunicaciónde datos de usuario, ni para habilitar un túnel de envío de paquetes entre dospuntos de una red. Por el contrario, es un estándar centrado en la robustez y laeficiencia energética y, como tal, debemos adaptar las características de los serviciosdel Soporte para que reduzcan al máximo la comunicación entre Nodos y, en todocaso, se limiten a cantidades de datos que puedan enviarse en ráfagas de informaciónmuy breves, de forma que no se comprometan los recursos de la red. Es relevanteel hecho de que, como la capacidad total del canal se reparte en 16 intervalos, la

227


velocidad de transmisión para un único Nodo está limitada a 15 transacciones porsegundo o, equivalentemente, una transacción cada 65ms. La electrónica de los motesno permite programar un bucle de ejecución con un periodo inferior a 100ms, porlo que se garantiza la capacidad para soportar el tráfico generado por un servicioque envía un mensaje de 81 Bytes cada 100 ms4. Si en un mismo mote tuviéramosprogramados varios dispositivos, el envío de información a la red debería ajustarsepara garantizar que la ocupación promedio del canal permanezca por debajo de15Kbps.

La elección del formato KVP como vehículo de intercambio se justifica por el cálculoanterior, combinado con el estudio de las características del tráfico esperado porlos servicios distribuidos en el Soporte. Por una parte, la diferencia en cuanto arendimiento que supone la cabecera KVP es del 3,94%, por lo que no encontramosninguna ventaja cualitativa al dimensionar la comunicación a partir de transaccionesMSG, con el inconveniente añadido de el protocolo debería definir un formato internoal Payload para todas las transacciones (a fin de caracterizar y poder manejarsu contenido) y la aplicación debería incluir todas las rutinas de composición yanálisis de estos campos, desaprovechando los métodos que incorpora la plataformade desarrollo de los equipos de prueba. En segundo lugar, una revisión de los Casosde Uso puede ayudarnos a caracterizar los diferentes flujos de información quevamos a tener en la red. Asumiendo que los datos de usuario van a ser más pesadosy con cabecera simples y los datos de servicio o control de la aplicación van aser ligeros pero con cabeceras más complejas, podremos seleccionar el formato detransacción más adecuado para las comunicaciones dentro del Soporte Técnico.

4Si asumimos que los mensajes de asentimiento automático consumen una cantidad insignificantede tiempo y banda e imponemos la condición de que los mensajes emitidos por el mote sólopueden ser generados y enviados desde una rutina controlada por el hilo principal de ejecucióndel programa (main), que es el que va a ejecutarse periódicamente.

228

13.1 Diseño

Caso Grado dedistribución

Tipo de tráfico Volumen detráfico

Frecuencia deintercambio


**** Control {sesiones,contexto, reloj}

** Continua

Iniciar Sistema *** Señalización deinfraestructura

* Puntual


**** Señalización de servicio **** Periódica


*** Señalización de servicio ** Frecuente


** Control {configuraciónde servicio}

*** Puntual


* Datos de servicio ***** Esporádica

ControlarArtefactos

* Datos de servicio ** Frecuente

DefinirReacciones

** Señalización de servicio *** Puntual


** Señalización + Datosde infraestructura

*** Continua


* Señalización deplataforma

** Mínima

Habilitar Ajustede Módulos

* Control {configuraciónde infraestructura}

* Fuera de ciclo

Cuadro 13.15.: Valoración del tráfico estimado por Caso de Uso

Sin entrar en una valoración cuantitativa del tráfico por servicio, nos vale la tablaanterior si observamos que el Soporte Técnico soporta un tráfico mayoritariamentede gestión, en el que los elementos más pesados surgen por la necesidad de mantenerlocalizados y sincronizados todos los dispositivos de la red móvil. Efectivamente, elSoporte contempla un plano de datos que prácticamente queda fuera del estudiodel Proyecto, ya que se limita a la transferencia de datos para la reproducción delos efectos finales (cuyo contenido depende de los medios, de las fuentes y de lascaracterísticas de cada Instalación) y, al margen de los casos que constituyen laPlataforma Abierta de Servicios, los casos que más volumen de tráfico generanestán completamente implementados en el Servidor o se comunican dentro de un

229


mismo Dominio y utilizando una API de librería, por lo que quedan fuera de laaplicación de una solución de comunicación para la interoperabilidad.

13.1.3.2. Características de cada enlace

Comunicación WSN - Servidor Cuando hablamos de la comunicación entre laWSN y el Servidor, hablamos de un intercambio de información que se está pro-duciendo entre componentes de Servicio. Como se han establecido los cálculos dedimensionamiento para todo el Soporte a partir de las características de trama deZigBee, ya conocemos los detalles de las cabeceras que componen los mensajes deldominio de red ZigBee, donde se incluyen tanto los motes como la pasarela. El blo-que WSN se completa con el enlace RS-232, que habilita la comunicación entre losDispositivos del Servidor y los Dispositivos de la Red. El intercambio de datos con losDispositivos remotos (del Servidor) es posible gracias a la adaptación Zigbee toOSGi (Z2O), que sigue una estrategia de apilamiento de encabezados inspirada enel estándar QinQ (802.1ad) de Carrier Ethernet.Para comprender el funcionamiento de Z2O, partimos de la estructura de las transac-ciones que ocurren dentro de la red ZigBee. Como queda reflejado en la figura acontinuación, los elementos significativos de una transacción se organizan en la ca-becera del nivel de aplicación (APS), la cabecera propia del mensaje KVP y en losdatos (Payload). Para la aplicación, las direcciones de red de los Nodos destino seobtienen por medio de búsquedas y solicitudes basadas en Descriptores Simplesy EndPoints, por lo que asumimos que el intercambio se produce en el contextode una conexión ya existente entre dispositivos o, al menos, de una situación deconocimiento del extremo receptor, tanto si es un Nodo de la red como si es el Servi-dor. Más adelante, cuando profundicemos en la arquitectura de la red y estudiemoslos mecanismos que facilitan el descubrimiento y la asociación entre Dispositivos,justificaremos la validez de esta premisa.Los mensajes Z2O se intercambian entre el Servidor y un Nodo dentro de la red, conla peculiaridad de que esta comunicación tiene lugar a través de la Pasarela. En reali-dad, el Nodo de red espera comunicarse con una entidad de su mismo dominio, esdecir, asume que el Servidor va a entender los mensajes en formato ZigBee, aunqueel Servidor no es un Nodo de la red y, de hecho, carece de dirección a la que puedadirigirse. Para facilitar la comunicación entre un Nodo WSN y el Servidor como sifueran entidades del mismo bloque, se construye una solución de adaptación apoya-da en la Pasarela, de tal forma que, siendo transparente para la comunicación, Z2Ogarantiza que cualquier dispositivo remoto es alcanzable para un dispositivo de laWSN a través de un EndPoint / Cluster de la Pasarela y, viceversa, un dispositivo delservidor puede comunicarse con un dispositivo WSN a través de un túnel habilitadopor la Pasarela en un EndPoint / Cluster específico. Toda comunicación dirigida ala pasarela con este encabezado específico desde la WSN será tratada por el pro-grama de la Pasarela como un mensaje Z2O que debe ser remitido al Servidor por elenlace serie y, en sentido descendente, los mensajes del Servidor se encapsularán en

230

13.1 Diseño

Figura 13.12.: Estructura de la trama Z2O en el dominio WSN

una trama con un encabezado adecuado para enviarlos al dispositivo destino en elformato adecuado.

Como vemos en la siguiente figura, el mecanismo de adaptación Z2O separa el do-minio de comunicación de los componentes de servicio del dominio de los nodos dered, de tal forma que la cabecera externa del mensaje (APS + KVP) sirve para es-tablecer el túnel de comunicación Z2O entre el Nodo origen y la Pasarela, mientrasque los datos del mensaje interior se almacenan en otra cabecera (APS + KVP) queforma parte del Payload. Esta cabecera no incluye datos de direccionamiento, yaque está destinada a un dispositivo fuera del dominio de red; de hecho, identifica aun componente de servicio instalado en el Servidor. Este caso plantea una situaciónsimilar al escenario de uso del etiquetado QinQ en Metro Ethernet, donde la reddel proveedor agrega su identificación VLAN al etiquetado VLAN del usuario; en elSoporte, el dominio VLAN del usuario correspondería a los dispositivos del Servidor,siendo la red proveedor la WSN. Este paralelismo nos puede ayudar a entender elhecho de que la WSN va a establecer un modo dominante en el intercambio entreDispositivos, lo que es coherente con el hecho de que el tráfico sea mayoritariamentede señalización entre componentes de servicio. Otros tipos de intercambio entre laWSN y el Servidor (como el envío de mensajes para la asistencia a la puesta enmarcha o los mensajes de depuración que se muestran por la interfaz del Coordina-dor WSN), siguen el mismo esquema de adaptación, pero utilizan un túnel con unencabezado distinto.

La Pasarela juega un papel fundamental en Z2O, al establecer el terminal de parti-

231


da o destino para los encabezados Z2O. Efectivamente, Z2O se basa en un túnel decomunicación dentro del dominio de red WSN que se conjuga con los mecanismosde comunicación Pasarela - Servidor por puerto serie. En este enlace, no es necesarioel intercambio de todos los datos de la trama ZigBee: basta con transmitir al des-tinatario los elementos que identifican la transacción y al dispositivo remitente, deacuerdo con una estructura de trama conocida. En este caso, lo más sencillo es in-corporar los elementos de las caberas APS y KVP, en el mismo orden en que aparecenen la transacción ZigBee.

Figura 13.13.: Estructura de la trama Z2O en el enlace RS232

Como queda detallado en la figura anterior, el enlace de comunicación se completacon la intervención de la Pasarela, que introduce el mensaje del Servidor en el túnelZ2O adecuado, añadiendo al mensaje recibido por el puerto serie la cabecera Z2O, conla que el Nodo destinatario dispone de suficiente información para desempaquetarel mensaje original procedente de un Dispositivo remoto.Desde el punto de vista de la implementación, los aspectos clave del mecanismo Z2Oson la identificación del túnel, el orden de los campos en el enlace serie, la correctadelimitación y la precedencia de los campos, asumiendo que los niveles físico y deenlace RS-232 garantizan una comunicación ordenada y sin errores.

Comunicación Servidor - UPnP La comunicación entre los componentes de ser-vicio implantados en la red UPnP y los componentes del Servidor es muy sencilla

232

13.1 Diseño

gracias a la librería Cling, ya que habilita un dominio de comunicación basado enmétodos UPnP para los componentes del Servidor. Esto significa que el Servidor in-corpora una capa que resuelve de forma transparente todo el intercambio con UPnP,de tal forma que todos los puntos de control del Bloque AV pueden estar instaladosen el Nodo Central del sistema y manejarse a través de la API de Cling. En definitiva,Cling va a embeber la pila UPnP en la máquina virtual Java y hacerla accesible alos componentes activos en la Plataforma OSGi.

Como ya hemos reseñado en la primera parte de este apartado, esta integracióntiene por objeto el intercambio de señalización. De hecho, el propio estándar UPnPespecifica que la resolución de la comunicación de datos queda fuera de su alcan-ce, preocupándose exclusivamente por garantizar la comunicación entre dispositivosproveedores y consumidores de contenido dentro de la misma red. Por ello, en eldesarrollo del Soporte Técnico, los detalles del formato de los mensajes que debenser reproducidos por el Bloque AV son secundarios a la disponibilidad de una redconectada de dispositivos manejados desde el Servidor de forma coordinada con loseventos de los que va informando la red WSN. Lo único que nos importa de estosmensajes es que van a seguir el mismo esquema de intercambio comando - respuestay que los elementos semánticos intercambiados están recogidos en el Profile, en losClusters manejados por el SimpleDescriptor que registra el Dispositivo de la redUPnP.

El aspecto clave en el diseño de la comunicación Servidor - Red AV radica en lacorrecta separación de los componentes de ambos Dominios, que pueden estar ins-talados en el mismo Equipo. A priori, no hay una decisión sobre la ubicación de losDispositivos UPnP que van a ejercer de fuentes y reproductores de contenido mul-timedia. Independientemente del Equipo donde se instalen, desde el punto de vistadel Soporte Técnico toda la Red AV se comporta como tres Dispositivos: Controlador,Emisor y Reproductor. El interlocutor de la red con los Servicios es el Controlador,de tal modo que la comunicación entre los componentes de Servicio y la red UPnPdebe pasar, en algún punto, por una Pasarela que adapte los artefactos de la lógi-ca de aplicación al dominio UPnP, en un ejercicio de adaptación similar al que seestá realizando con ZigBee. En el caso de UPnP, los mecanismos de adaptación losdispone la librería Cling, por lo que el desarrollo propio del Servidor sólo necesitade los componentes que procesen el diálogo de los Servicios para hacerlo manejablepara los componentes UPnP.

Comunicación entre capas del Servidor Dentro del Servidor, la comunicación seresuelve por mecanismos puramente OSGi. La señalización de Servicios respeta elProfile y la comunicación de la infraestructura se desarrolla de forma paralela, porlos mismos medios, pero con su señalización independiente (correspondería a unplano de control paralelo). En general, la comunicación entre componentes dentrode una capa del Servidor se realiza por medio de funciones de las interfaces de co-municación de los componentes (API), mientras que la comunicación entre capas se

233


realiza mediante Eventos o mecanismos de conexión entre componentes de OSGi(Declarative Services). Los componentes que implementan las capas de integra-ción de las redes del Soporte utilizan estos mecanismos en su faceta de comunicacióncon el Servidor, no así con el extremo de red, que depende de la librería y el enlace decomunicación utilizado. Estos métodos se presentan en un apartado separado antesde analizar la arquitectura del sistema en el capítulo siguiente (ver Sección 15.4).

13.1.3.3. Planos de comunicación

La Tabla 13.15 puede combinarse con la caracterización de los flujos de tráfico quese desprende del protocolo de comunicación, identificando los distintos planos decomunicación entre los Bloques del sistema. Un plano de comunicación refiere eluso de una torre de protocolo y un modo de intercambio, necesario para controlarel orden de diálogo entre las entidades que manejan datos de dicho plano.

Siguiendo la notación telemática, la comunicación se desarrolla en tres planos (da-tos, señalización / control y gestión), que conducen tipos de tráfico distinto y tienenpapeles complementarios en el desarrollo de servicios. La relación entre estos planosnecesita del conocimiento de la aplicación concreta para adquirir todo su sentido, yaque hay aplicaciones que generan sólo tráfico de control (ejerciendo un servicio auxi-liar para un flujo continuo de datos) y hay aplicaciones que necesitan una conexiónprevia por medio de señalización para poder enviar los datos hasta su destinatario.En el Soporte, esta relación queda recogida en los Casos de Uso, como se refleja enla Tabla 13.14, a partir de la cual se identifican los planos de comunicación recogidosen la Tabla 13.16 y se ubican los componentes que los soportan.

234

13.1 Diseño

Caso Parte:Enlace

Plano Ejemplos detráfico

Entidades


AG: WSN -SRV - AV - UI

Control +Señalización

Control de sesiones,recuperación decontexto, reloj

Dispositivos +Plugins (AG)

Iniciar Sistema AG: WSN -SRV - AV - UI

Control Presentación (registro)en el SRV

Primitivas (AG)


PAS: WSN -SRV

Señalización Señalización delocalización

Dispositivos(PAS)


PAS: WSN -SRV

Señalización Señalización decontenido

Dispositivos(PAS)


PAS: WSN -SRV - AV

Señalización Configuración deservicios (escenas)

Dispositivos(PAS)


PAS: WSN -SRV - AV

Datos Datos multimedia Dispositivos +Plugins (PAS)

ControlarArtefactos

PAS: WSN -AV

Datos Señalización multimedia Dispositivos(PAS)

DefinirReacciones

PAS: SRV - UI Señalización Definición de escenas Dispositivos +Plugins (PAS)


AG + PAS:SRV - UI

Señalización+ Datos

Asistencia a la puestaen marcha

Primitivas (PAS)+ Plugins (AG)

Cuadro 13.16.: Planos de comunicación

13.1.4. Diseño de servicios

El Soporte Técnico es una aplicación para instalaciones de arte interactivo basadoen una infraestructura de integración sobre la que opera una plataforma abiertade servicios. La infraestructura subyacente conecta distintas redes para formar unajerarquía en estrella en torno al nodo central - el Servidor. Sobre esta topología,se despliegan una serie de Servicios, que responden a Casos de Uso planteados alobjeto de dar contenido y capacidad de control a la instalación interactiva. EstosServicios no agotan la capacidad creativa de una instalación, pero establecen mecanis-mos muy concretos para canalizarla. En cierto modo, los Servicios se han concebidocomo herramientas de creación, cubriendo las facetas de la obra que requieren untratamiento tecnológico, pero van mucho más allá, de forma que el sistema admitecambios en la implementación de los Servicios, nuevos Servicios dentro de la lógica

235


de la aplicación y, en general, una gran flexibilidad en la gestión del ciclo de vidade las entidades que participan en estos Servicios. Estas prestaciones del sistemaderivan de los principios de diseño y, por tanto, son anteriores a cualquier definicióno desarrollo.El estudio del diseño de servicios comprende, sobre todo, dos aspectos: en primerlugar, aportar una descripción técnica del concepto, con indicación de los elementosque los componen, sus atributos y métodos. Esta descripción pasa necesariamentepor el concepto de Componente de Servicio, como artefacto de programación enel que se va a implementar una parte del servicio dentro de un Nodo del sistema.Cuando hablemos del modelo de Servicio, estaremos presentando un esquema formalde intercambio entre entidades materializadas en Componentes de Servicio. Lasegunda parte del diseño se centra en la descripción del Contrato de Servicio,poniendo en relación los elementos del Contrato con el Profile de aplicación, conec-tando así con el diseño global de la aplicación y la lógica de Dispositivos.

Componentes de Servicio

Un Componente de Servicio es una artefacto compuesto por clases, que exhibe unao varias interfaces con las que conecta con el resto del sistema, con la peculiaridad deque sus interfaces están regladas por contratos de Servicio. Muy suscintamente, ladiferencia entre una interfaz de componente convencional y un contrato de servicioes que, mientras la interfaz define sus propios métodos de interacción, el contrato sedefine en términos de transacciones de datos, utilizando métodos genéricos para sudesarrollo. Un componente puede actuar como proveedor, consumidor o mediadordel Servicio - facilitando a otro componente la facilidad de acceso al mismo. Según lacomplejidad de la arquitectura, podemos encontrar otros componentes participandoen la cadena de suministro, pero siempre tendremos un componente que declara unServicio - publicándolo en la Plataforma - y uno o varios componentes que accedena dicho Servicio para cumplir su desempeño.Hemos insistido mucho en describir un servicio como una facilidad reglada, porque,una vez entremos en la implementación, corremos el riesgo de confundir el Serviciocon el objeto declarado en la Plataforma. En realidad, dicho objeto sirve tan sólocomo puerto de conexión entre el proveedor y el consumidor del Servicio y éstos nopueden ponerse en relación si ambos no manejan previamente una descripción delintercambio y no establecen un acuerdo en los mecanismos de llamada y los formatosde datos.Hasta aquí, sin embargo, no hemos hecho más que hablar de modularidad y dise-ño de componentes; con lo dicho hasta ahora, podríamos concluir que los distintosComponentes de Servicio comparten una API y esto no es cierto en SOA. ¿Cómopodemos asegurar la compatibilidad entre interfaces cuando se trata de conectarcomponentes implementados en nodos remotos, en tecnologías distintas? ¿Qué in-fraestructura debería actuar como maestra en la conexión de componentes: la más

236

13.1 Diseño

abstracta, la proveedora, la más cercana a la interfaz de usuario o a las fuentes dedatos? Si equiparamos la Plataforma de Servicios con una capa distribuida decomponentes dinámicos, surgen demasiadas dudas sobre el diseño de la infraestruc-tura de integración, porque, o bien estamos complicando el proceso de desplieguepara garantizar la coherencia en el arranque de los Servicios, o bien estamos debili-tando la cohesión para garantizar la conectividad dentro del Servicio. La solución aeste problema empieza por la descripción de un modelo aplicable en todo el sistemadentro de la misma lógica de aplicación, de tal forma que todos los Componentes querespondan al modelo puedan comunicarse utilizando los mismos mecanismos, a tra-vés de la red formada por la Infraestructura de Integración, como si estuvieranconectados en un bus. En la Figura 13.14, tenemos este modelo:

Figura 13.14.: Lógica de estados de un componente de servicio

En el modelo de Componente de Servicio, encontramos elementos que pertenecena dos planos de la aplicación. Por una parte, el componente es un módulo de fun-ción, que desarrolla una parte de la aplicación fuera del Profile. Esta funcionalidad espara el Profile una caja negra, de la que sólo se observan, desde la perspectiva de laPlataforma de Servicios, cambios en el modo operativo. Como refleja el esque-ma, los cambios internos de los componentes de servicio se expresan medianteVariables de Estado, que son Atributos del Profile; del mismo modo, las transicionesentre los diferentes estados se describen, fundamentalmente, en términos de Atribu-tos. Esto quiere decir que, para el diseño del Soporte, los componentes de Servicioactúan como máquinas de estado, perfectamente definidas por medio de sus vectores

237


de estado y sus posibles trayectorias.

La asociación entre Variables de Estado y Atributos no es una imposición de diseño,sino una consecuencia de la relación entre Componentes de Servicio y Dispositivos.Aunque no aparece reflejada en el esquema, existe una ligadura entre los Atributosque definen los estados de un Componente y los Clusters contenidos en el Descriptorque caracteriza al Dispositivo. Efectivamente, el Componente es el objeto de progra-mación que toma el control del EndPoint donde se instala el SimpleDescriptor y esquien recibe de la infraestructura el permiso para enviar y procesar mensajes en nom-bre del Dispositivo. Esto es, ni más ni menos, la traducción al modelo de aplicación dela descripción que hacíamos al comienzo del apartado sobre los Componentes. Comovemos, el Componente de Servicio actúa como nexo de unión entre la Plataformay la Infraestructura. Desde el punto de vista de la arquitectura, es un componentedesplegado por la Infraestructura en el nivel de aplicación, pero tiene acceso di-recto a los EndPoints y, a través suya, puede establecer conexiones con Componentesalojados en Nodos remotos. Esta accesibilidad a la red, unida a la facilidad paracomunicarse utilizando parámetros de los Descriptores (que conoce porque son losmismos Atributos que describen su Estado), hacen del Componente el material básicopara construir la Plataforma de Servicios.

Modelo de Servicio

Cuando estudiamos el Tabla 13.14, descubrimos que una parte muy importante delAlcance del Proyecto queda recogida por la Plataforma de Servicios. En todomomento, hemos utilizado esta denominación para designar la parte de la aplicacióndonde quedan implementados los Casos de Uso designados en la tabla, pero estono quiere decir que todos los elementos que participan en su implementación seanServicios. De hecho, al presentar las distintas partes del Soporte, aclaramos que laPlataforma Abierta de Servicios incluye recursos y mecanismos de composi-ción que son un apoyo a los Componentes de Servicio, pero que no responden almodelo del apartado anterior.

El modelo de Servicio describe el mecanismo de intercambio de mayor nivel de abs-tracción del Soporte, en el que han desaparecido los Equipos y Dominios y la co-municación se produce entre Dispositivos. La ubicación de los Nodos donde residenéstos no es relevante para el desarrollo de los Servicios, ya que corresponde a laInfraestructura de apoyo la resolución de las direcciones y la adaptación de pro-tocolos necesaria para alcanzar físicamente al Dispositivo remoto. A nivel de Servicio,los mecanismos de conexión e intercambio se apoyan en las identidades de los Dis-positivos y confían en la coordinación en torno al Profile de aplicación. Por tanto,en todo escenario en el que podamos aplicar esta solución, basada en la lógica deDispositivos y el dominio de aplicación contenido en el Profile, estaremos utilizandoel modelo de Servicio. Cualquier arquitectura que se apoye en la Infraestructurapara facilitar el despliegue de un Servicio - ya sea un plugin para crear una interfaz

238

13.1 Diseño

con el usuario, una librería para el acceso a un recurso de información o una herra-mienta de traducción de datos, un puerto de conexión remota o un componente devigilancia frente a inconsistencias, bucles y pérdidas de sincronismo - forma partede la Plataforma de Servicios.

En el Soporte Técnico, un Servicio tiene tres características definitorias: implementaun Caso de Uso, es propiedad de un único Componente de Servicio registradoen cada equipo y es accesible a través de un Contrato. Cuando entremos en la im-plementación del modelo de servicio en los bloques del Soporte, veremos que losServicios quedan agrupados dentro de un mismo Descriptor Simple, registradosen el mismo EndPoint, e incluso compartiendo espacio con funciones que tienen asig-nado un Cluster y no se definen como Servicios en términos SOA. En todos los casos,veremos cómo los datos del servicio están protegidos dentro de un componente yel nodo implementa un autómata de diálogo que responde al papel asignado porel Caso de Uso para el Dispositivo instalado en el Nodo, mientras que las otrasfunciones se difuminan en el programa, no poseen una estructura de datos propia ono aparecen en ningún diálogo.

No debemos confundir el Descriptor Simple (que se refiere a un Dispositivo) conel Contrato de Servicio: un mismo tipo de Servicio puede ser implementado por Dis-positivos con Descriptores distintos, siempre que respondan a las especificacionescontenidas en el Contrato. Los Descriptores corresponden a los agentes del Servicioy, por tanto, pueden ser complementarios (respondiendo a un esquema de servicioproveedor /consumidor) o ser simétricos (lo que respondería a un modelo de inter-cambio entre pares). Cada Descriptor deriva de la implementación del Servicio,recogido en su Contrato, dentro de un Rol específico del sistema. Esta unicidad nospermite simplificar y definir un Servicio como una pareja EndPoint / Cluster acti-va en la aplicación de un Nodo, incorporando así la noción de un Componente deServicio integrado en el programa, un diseño conforme al Contrato de Servicio yuna comunicación basada en el Profile.

El modelo de Servicio está contenido, en definitiva, en el Contrato. Lo que vamos aencontrar en esta especificación es una definición de los inputs y outputs del Servicio,con sus métodos de intercambio. En términos del Servicio, un intercambio se definecomo una Acción y su Efecto resultante. Como hemos representado en el siguien-te esquema, una Acción es un conjunto de Operaciones, cada una de las cuales seimplementa como una transacción entre Dispositivos expresada por medio de Ope-rables. Para el Servicio, la naturaleza física de los Operables no es relevante, por loque, en principio, cualquier clase que implemente la interfaz de operación es válidapara el Servicio; sin embargo, como vemos en el diagrama, los elementos Operablesson Variables de Estado, por lo que el conjunto de variables que pueden utilizarseen las transacciones se reduce a los Atributos propios del Cluster manejado por elComponente de Servicio. Así, se establece un mecanismo por el cual la ejecuciónde Servicios influye en la dinámica de la Plataforma, ya que un intercambio puededesencadenar una Transición en el Estado de su huésped.

239


La dinámica del componente de servicio y la secuencia de diálogo entre dispositi-vos quedan fuera del Contrato. Por esto mismo, los componentes cambian de estadode acuerdo con el ciclo de vida de la aplicación - fuera del modelo de servicio - ylos intercambios se simplifican a dos pasos: comando / acción y efecto / respuesta.Siempre que se den las condiciones de ejecución para una transacción en curso, elcomponente ejecutará su tarea con los valores recibidos y devolverá la respuestaadecuada. Esta mecánica es suficiente para cubrir todos aquellos intercambios en losque el modelo de servicio aporta valor para el Soporte, tanto en modo de configura-ción (por ejemplo, repartiendo una etiqueta a todos los nodos que participen en losefectos de una zona) como en modo de ejecución (distribuyendo una señal para quetodos los nodos de zona ejecuten en una marca de tiempo una escena determinada).

Figura 13.15.: Modelo de Servicio

El esquema está inspirado en el estándar UPnP, dentro el cual los dispositivos secomunican por servicios, ocultando la programación de los componentes a la redy ofreciendo exclusivamente una interfaz de comunicación a través de variables deestado. En el Soporte, podemos trasladar estos conceptos con igual facilidad alámbito WSN o al Servidor, ya que nuestra Plataforma de Servicios va a extendersetrasversalmente, siguiendo el Profile, aprovechando las prestaciones y los elementosheredados de las tecnologías empleadas.Las relaciones del modelo anterior tienen implicaciones muy concretas en el diseño de

240

13.1 Diseño

la plataforma abierta de servicios . Para empezar, se equiparan los conceptosde Cluster y Servicio, ya que, para una misma versión del servicio, todos los atributosdel servicio para un Dispositivo deben pertenecer al mismo Cluster y, en consecuen-cia, los Operables de entrada y salida pertenecen al mismo subconjunto. Implica, ensegundo lugar, que los estados de servicio lo son en realidad del componente quelo desarrolla y sólo pueden expresarse por medio de Atributos del Profile. Por tan-to, cualquier mensaje enviado por un Servicio a un determinado destino EndPoint/ Cluster con un código de Comando puede ser interpretado como una transacciónde Atributos conforme a la Acción predeterminada para ese Comando. Este modeloes igualmente válido tanto para la comunicación WSN como para UPnP, cambiandoúnicamente en cada Dominio el formato de los mensajes para hacerlo acorde al proto-colo: en el caso ZigBee, tendremos mensajes dirigidos a un Dispositivo, caracterizadopor su dirección de red y los paramétros EndPoint / Cluster / Comando / Atributopropios del estándar ZigBee codificados de acuerdo con el Profile; para la red UPnP,tendremos dispositivos que implementan un servicio que registra una serie de méto-dos que son invocables, por lo que, siguiendo el mismo esquema, las llamadas iránreferidas al Dispositivo (identificado por su URI o cualquier identificador unívoco enla Red) y las variables de los métodos de servicio se identificarán con los Atributos delProfile. Las relaciones dentro del Servidor también respetan el Profile, pero, dada sucomplejidad, se verán en un apartado independiente como parte de la Arquitectura.Las relaciones de la lógica de servicio sirven como criterio para asignar y validar elcomportamiento de los distintos Roles del sistema, ya que, una vez estemos en dispo-sición de la lista de Servicios requeridos por el Soporte Técnico, podremos identificarlos distintos papeles que responden al mismo tipo de Servicio, así como las Accionescomplementarias que deben realizar para llevar a cabo el objetivo del Servicio. Ade-más, tendremos que indicar cómo es la comunicación entre Dispositivos, expresadaen términos de Comandos y Respuestas. Como vemos en la Figura 13.15, aunquepodemos imaginar que son transacciones propias del Protocolo, los Comandos sonuna especie de “disparador” de la Acción, del mismo modo que las Respuestas pue-den ser parte del Efecto producido por la ejecución de una Operación. La Plataformade Servicios se construye en torno a los elementos del Profile y los Contratos mante-niendo tres reglas contigentes: un dispositivo no puede invocar sus propias acciones(hay un orden espacial), un consumidor tiene que esperar a la disponibilidad delservicio para consumirlo (hay un orden temporal) y una acción no se ejecuta si noviene de una llamada válida (hay un orden sintáctico y semántico).

Capas del Sistema

A lo largo de este capítulo, hemos presentado diferentes criterios para ubicar la lógicade aplicación en la estructura de código del Soporte. Sin entrar en la Arquitectura,dividimos la aplicación por sus características SOA en una parte de Infraestructuray una Plataforma Abierta de Servicios que opera sobre ésta. Fijándonos en las tec-nologías y redes integradas, definimos cuatro Bloques: WSN, Servidor, AV e Interfaz

241


de Usuario; en todos ellos se aplica el modelo ontológico, adaptando la representa-ción de datos para permitir la comunicación entre dispositivos alejados. El estudiode estos mecanismos de comunicación nos permitió dividir el tráfico en tres pla-nos complementarios: Señalización, Control y Datos de Servicio. Estas perspectivasmantienen un vínculo muy fuerte, debido a su relación con la lógica de la aplicación.En la Subsección 15.3.2 de los Anexos se aplica la lógica de aplicación a la arqui-tectura de protocolos de cada equipo. Miremos el Soporte por donde lo miremos,encontramos la misma jerarquía de abstracción, en la que se están apilando las pri-mitivas de comunicación, los mecanismos de integración y, sobre ellos, los medios quecomponen la plataforma de servicios. La frontera entre la parte de infraestructuray la plataforma la marca el bus que permite la comunicación horizontal entre servi-cios; en el bloque WSN, este bus vendrá implementado sobre Z2O, mientras que enUPnP se apoyará en los mecanismos UPnP, accesibles a través de la librería Cling.La superposición de varios planos de comunicación también se refleja en la arquitec-tura de protocolos, donde podemos encontrar sistemas que, para una misma interfazde comunicación, incorporan dos torres de protocolos. En general, la comunicaciónde datos y señalización propia de la plataforma de servicios discurre por el mismocanal (diferenciándose por sus formatos de trama), mientras que la señalización decontrol y señalización de la infraestructura utilizan mecanismos independientes.Esta simetría del sistema es consecuencia directa del modelo lógico que hemos pre-sentado y es el fundamento que permite al Soporte Técnico satisfacer el requisitode Interoperabilidad (Elemento 2d). Formalmente, en el Soporte Técnico se handispuesto siete niveles de abstracción; conjugados con los bloques, tenemos la arqui-tectura de la solución propuesta que ya presentamos en la Figura 4.13.

Concluyendo la lógica de aplicación, en la figura se han representado los dos blo-ques periféricos (WSN en rojo y AV en verde) y la arquitectura del Servidor, que

242

13.1 Diseño

llega hasta la interfaz de administrador (Web). En este modelo, no vemos la im-plantación de los servicios, pero sabemos que los dispositivos del servidor estaránalojados en la Capa de Participación y que sus homólogos en las redes deberíanestar en los bloques grises, donde se está reproduciendo especularmente la jerar-quía de abstracción, adaptada a la arquitectura de los equipos. Los componentesde Servicio implementados sobre los equipos finales (inputs, efectos o multimedia)no poseerán las mismas propiedades SOA que los componentes de alto nivel delservidor, lo que justifica la necesidad de una Capa de Integración que uniformela representación de datos conforme al Profile. Por encima de este nivel, donde seimplanta la plataforma de servicios, tenemos la capa superior del sistema - llamadade Presentación - destinada a garantizar la capacidad de gestión del ciclo de vidadel código y, fundamentalmente, a habilitar un medio de información para el admi-nistrador, cumpliendo así los requisitos de manejo remoto, interfaz gráficay plasticidad (Elemento 1a, Elemento 3a, Elemento 3c).

Definición de Servicios

Todo lo anterior se aplica en la definición de los Servicios que componen el Soporte.Siguiendo la misma estructura paso a paso del capítulo, podemos recapitular:

1. La necesidad de incorporar un Servicio a la plataforma del Soporte respon-de a un Caso de Uso que puede implementarse de forma desacoplada delresto (o, al menos, parte de la secuencia del caso). Estamos hablando de unaaproximación teórica, para esbozar las características generales de este nuevoservicio. Por ejemplo, la zonificación de la instalación viene directamente dela resolución del caso Definir modos de control, afectando también al casoControlar el contenido y a Definir reglas de medida. Puede tratarsecomo un servicio porque los demás servicios van a contar con la existenciade una organización del sistema (las zonas) y van a interactuar con ella deforma completamente transparente, sin afectar a su configuración ni evoluciónposterior. Lo mismo ocurre con la localización: muchos servicios suponen el co-nocimiento de las coordenadas del nodo en movimiento (entre ellos, la propialocalización), pero no les afecta cómo ni cuándo se obtenga esta información.

2. Las entidades que van a participar en el Servicio - como proveedores, consu-midores o intermediarios - tienen que formar parte de la Ontología. Conside-rando los roles establecidos y las entidades recogidas en este modelo, podemosidentificar el ámbito del servicio (bloques, dominios) y establecer una lista deDispositivos candidatos (de momento, sólo como etiquetas propias del serviciopara un nodo o un agente alojado en el servidor). En algunos servicios, laidentificación de los dispositivos se desprende naturalmente del caso de reali-zan - como ocurre con la localización. Hay servicios que, por su alcance global(sincronización), afectan a todos los equipos. Por último, algunos casos sólopueden resolverse con un compromiso entre los criterios de diseño AmI y las

243


limitaciones tecnológicas, como pasa con la gestión escénica, que debe per-manecer en el centro del sistema para llegar a todos los bloques actuadores,contraviniendo el diseño subsidiario preconizado en el Análisis.

3. Entramos en el modelo lógico del Servicio:

a) ¿Qué datos son necesarios para desarrollar los usos del servicio? Observarque hablamos de los datos propios del servicio, que son exclusivamenteaquellos que se intercambian entre dispositivos. Por agilidad o claridad,pueden incorporarse al modelo todas las estructuras privadas, recalcandoque no forman parte del contrato de servicio. Las referencias estudiadasapuntan a un dimensionamiento del diccionario de los servicios propor-cional a la capacidad y disponibilidad del canal. En ZigBee, por ejemplo,tenemos mensajes cortos y rápidos, mientras que en UPnP pueden sermuy pesados sin comprometer los recursos de la red. En todo caso, elcontrato de servicio se aplica a todo el sistema; no puede cambiar entredominios.

b) ¿Quién posee la información? ¿Quién la reparte? ¿Quién la procesa? Losflujos de datos establecen el papel de cada nodo en el desarrollo del ser-vicio. La mayoría de los servicios del Soporte responden a la topología“productor” - “consumidor”, pero la asignación de los papeles no siemprees directa. Pensemos, por ejemplo, en la localización: los productores sonlas balizas fijas y los principales consumidores los nodos móviles, pero,¿qué papel ocupa el servidor? Desde nuestro punto de vista, se interpre-ta como un proveedor de información refinada, aportando capacidad decálculo para procesar la información bruta recibida desde la red.

c) Siguiendo con el punto anterior, debemos preguntarnos cómo es la cadenade suministro de información. Debemos definir la actividad que se desa-rrolla aisladamente en cada nodo y los cambios internos que habilitan aldispositivo para proveer un servicio o lo empujan a buscar un servicioen la red, hasta concluir en el punto en el que hay una transacción entredos dispositivos interesados. El servicio de gestión escénica, por ejemplo,pasa por dos estados claramente diferenciados: en el primero, el servidortiene que volcar una configuración coherente en todos los equipos perifé-ricos conforme van estableciendo una conexión; en el segundo, un nodode cada zona debe encargarse de mantener la coordinación y controlarla ejecución de las secuencias, de acuerdo con las condiciones de disparoprogramadas (número de visitantes, entrada o salida, etc.). Claramente,los flujos de información son distintos en ambos momentos.

4. Con estos datos, podemos pasar al dominio de análisis. El objetivo final deesta etapa es, efectivamente, redactar el Contrato de Servicio. Para ello:

a) Se reservan los Clusters necesarios para el servicio y lo ubicamos en losEndPoints registrados. Un servicio puede necesitar más de un Cluster si

244

13.1 Diseño

mantiene un flujo de señalización y datos de forma ininterrumpida o bienimplementa más de un Caso de uso. Considerar con ello que, según lostipos de datos admitidos en el Profile, la aplicación puede registrar 256Clusters, cada uno con 65536 Atributos. Para el diseño del Soporte, seha mantenido el criterio 1 Servicio = 1 EP / Cluster, reuniendo en unmismo EP aquellos servicios que mantienen mayor afinidad por roles parasimplificar y acelerar las conexiones en red.

b) Se identifican los Atributos, con su tipo de datos y su sentido de acceso(sólo lectura, sólo escritura, lectura / escritura).

c) Se definen las acciones, en términos de Comandos y Respuestas esperadas.

1) Un comando es una transacción con un encabezado de servicio (ID dedispositivo, servicio, código de transacción), una trama de operandos(lista de atributos) y datos complementarios: este contenedor adicio-nal sirve para enviar información del usuario entre las estructurasprivadas de cada dispositivo, cuando el paso de atributos no soportatoda la información de la transacción. En la localización, por ejem-plo, se mantiene un proceso de refinado en el Servidor a partir de lasmuestras de señal obtenidas en tiempo real por los nodos móviles. Es-te proceso complementario sirve para hacer el seguimiento del nodoy calibrar los parámetros del motor de localización, implementado enlos visitantes. Siguiendo el ejemplo de otras aplicaciones, se ha defi-nido una lista reducida de atributos para las transacciones generales,referidas a las coordenadas y el método de localización, dejando losdatos de estas ráfagas de proceso fuera de los atributos, referidos tansólo por un encabezado correspondiente a una transacción “especial”.Algo parecido ocurre en el servicio de control escénico, donde se hacenecesario transportar una configuración de escena o una secuencia dereproducción en términos que quedan fuera de la señalización generalde intercambio del servicio, referida a configuración o disparo de laspropias escenas.

2) Con respecto a las respuestas, pueden entenderse como transaccio-nes de vuelta con información procesada por el componente de servi-cio, con una estructura similar a un comando, o puede ser simplementeuna señal de asentimiento, aceptación o finalización sin incidentes dela acción realizada.

d) Con los envíos y respuestas, queda determinada la direccionalidad de losClusters de servicio, por lo que pueden establecerse los mecanismos deconexión (por complementariedad de los descriptores, por búsqueda deun determinado descriptor...)

e) Debe establecerse en qué estado del ciclo de la aplicación se realiza cadatransacción y cómo se refleja el estado del dispositivo en los atributos de

245


los Cluster de servicio. El ciclo de vida de la aplicación es el mismo paratodos los componentes, de modo que las señales de transición o cambiose distribuyen por la Infraestructura hasta la Plataforma de Servicios; noobstante, los dispositivos pueden permanecer inactivos hasta disponer deinformación o una configuración válida y pueden borrar la configuraciónde sus clientes si sufren algún problema o se interrumpe su secuencianormal de ejecución. Por tanto, el ciclo de vida afecta a la disponibilidadde los servicios y esto afecta de vuelta al ciclo de vida. Imaginemos, porejemplo, que el proveedor del servicio de sincronización detecta una derivaen un dispositivo y no puede recuperarlo porque tiene un nivel crítico debatería. Una gestión completa de la sincronización podría llevar al equipocompleto a un modo de anulación hasta que se reemplace su alimentación,afectando con ello a todos los dispositivos alojados en el mismo.

f ) La implantación del dispositivo en el equipo debe hacerse conforme alentorno de desarrollo del dominio (OSGi, UPnP, ZigBee). Para facilitareste desarrollo, se han incorporado a la programación herramientas detratamiento y se presentan en la Arquitectura patrones de las partesmás complejas, así como una prueba de concepto en el código aportado.

Completando este paso a paso, en la Subsección 15.3.1, se presenta una descripciónde los usos y diálogos de cada uno de los servicios planteados para el Soporte. Enla sección directamente a continuación, se presentan formalmente estos servicios,incardinados en la Arquitectura general de la aplicación.

246

Soporte técnico para una instalación de arte...

Documents

Transcript of Soporte técnico para una instalación de arte...