10. Normas y referencias

10.1. Normativa aplicada

ZigBee

El protocolo ZigBee ha sido desarrollado para facilitar un medio de conectividadinalámbrica de baja potencia para un amplio rango de aplicaciones que realizantareas de monitorización y control. Es un estándar abierto de alcance mundial,gestionado por la ZigBee Alliance.La especificación ZigBee, denominada oficialmente ZigBee 2007, define una topolo-gía en malla total capaz de soportar hasta 64000 nodos sobre la misma red. Estápensada para admitir un espectro de dispositivos muy amplio, de cualquier indus-tria y aplicación, dentro de la misma red de control. ZigBee admite una relaciónmuy extensa de aplicaciones interoperables, incluyendo automatización en edificios,cuidado de la salud, domótica, eficiencia energética, servicios de telecomunicacionesy dispositivos de gestión de ventas en establecimientos comerciales.El estándar ZigBee ha sido estudiado con anterioridad en trabajos académicos de laEscuela de Ingenieros; sobre todo, se han analizado las características del nivel deenlace 802.15.4 sobre el que se despliega el estándar y, también, dentro de ZigBee,las funciones de red. El desarrollo del Soporte Técnico parte de este conocimientoprevio de la tecnología y se centra en el nivel de aplicación ZigBee, motivo por elque vamos a pasar rápidamente por los aspectos generales para detenernos en lascapas superiores y en el modelo de aplicación que podemos desarrollar a partir dela librería del fabricante de los equipos con los que vamos a trabajar.

Resumen Técnico1

La especificación ZigBee se presenta en dos Feature Sets o implementaciones:ZigBee (simple) y ZigBee PRO. La versión ZigBee está diseñada para dar soportea redes más pequeñas, con cientos de dispositivos en una misma red. La versiónPRO es la opción más popular para los desarrolladores y es la especificación debase para el desarrollo de los estándares de aplicación para la ZigBee Alliance. EnZigBee PRO, se maximizan todas las capacidades de la versión simple, añadiendo

1Extraido de [?, ?]

141

Capítulo 10 Normas y referencias

facilidades de uso y soporte avanzado para redes más extensas, compuestas por milesde dispositivos. Ambas versiones han sido diseñadas para colaborar, garantizandoasí la usabilidad y la estabilidad a largo plazo.ZigBee completa la torre de protocolos 802.15.4 del IEEE añadiendo una capa dered y seguridad y un framework de aplicación. Desde sus orígenes, la ZigBee Allianceha ido desarrollado estándares complementarios, denominados formalmente profilesde aplicación, que pueden ser utilizados para crear soluciones abiertas sin atadurasde mercado. Para aplicaciones específicas donde no se requiere una compatibilidadcon otras soluciones, los fabricantes tienen la libertad de crear sus propios profiles.Esta segunda aproximación es la que hemos seguido en el Soporte Técnico, ya queel escenario de uso no se correspondía con ninguno de los tipos de aplicación dedominio público y la solución no está pensada para integrar otros dispositivos de losya contemplados.

Frencuencia y alcance ZigBee puede funcionar sobre un enlace radio en tres ban-das RF distintas: 868 (sólo en Europa), 915 (en América y Asia) y 2400 MHz. Elacceso a estas bandas se apoya en la normativa ISM de la ITU-T, según la distribu-ción aplicable de cada zona geográfica.Las características de cada una de estas bandas RF se resumen en la tabla siguiente.

Figura 10.1.: Características RF de ZigBee

Como vemos, aunque las bandas de frecuencia en 868 y 915 MHz ofrecen algunasventajas, como una menor saturación de usuarios, menor interferencia, absorción yreflexión de señal, la banda de 2400 MHz se utiliza con mayor frecuencia, por variosmotivos:

Disponibilidad universal.Mayor número de canales y mayor tasa de transmisión.Menor consumo de potencia.Banda RF manejada y aceptada por el mercado.Modules

ZigBee incorpora medidas para evitar la interferencia radio. Una de ellas es la ca-pacidad para detectar automáticamente la mejor frecuencia en la inicialización delsistema. También, si es posible, puede adaptarse a un entorno RF cambiante, selec-cionando automáticamente otro canal si la comunicación en la frecuencia de trabajose vuelve difícil.

142

10.1 Normativa aplicada

La distancia de transmisión depende del entorno de trabajo; por ejemplo, afecta mu-cho la instalación en interiores o en exteriores. Un módulo común (con una potenciade emisión de 0dBm) puede alcanzar un rango de unos 200 metros en área abierta,pero dentro de un edificio su cobertura se verá reducida por factores como la absor-ción, reflexión, difracción y efectos de onda estacionaria, causados por las paredes ydemás objetos sólidos. Módulos de mayor potencia (por encima de 15dBm) puedenconseguir un rango cinco veces superior. Además, la distancia entre dispositivos le-janos puede aumentarse en algunas topologías de red, utilizando nodos intermedioscomo repetidores.Para el desarrollo del Soporte Técnico, la elección de la banda en 2,4GHz es obli-gatoria, por dos motivos. El primero y fundamental, porque los equipos de pruebautilizados incoporan un chip radio a 2,4GHz y no pueden trabajar en las otrasbandas, pero además, como veremos, porque las especificaciones de tráfico para losservicios desplegados por la aplicación no se pueden cumplir con las prestaciones delestándar en 800 o 900MHz.

Características de comunicación ZigBee utiliza diferentes técnicas para garanti-zar la integridad de la comunicación.A nivel físico, al apoyarse en la capa 802.15.4, la transmisión en 2,4GHz sigue unacodificación QPSK, con símbolos de 4 bits y secuencias de chip de 32 bits. En el nivelde enlace, el esquema de acceso al canal es CSMA-CA y la estructura de supertramaspuede configurarse para seguir un patrón síncrono de entramado (a partir de señalesde ajuste enviadas por el Coordinador de la red) o un patrón asíncrono. La comu-nicación puede configurarse para exigir el intercambio de asentimientos positivos,disponiendo de total libertad para ajustar el tamaño de las ventanas de transmisióny los mecanismos de asignación de crédito.En el nivel de red, algunas topologías incorporan mecanismos para garantizar elenrutamiento de los mensajes hasta su destino, mientras que otras confían plena-mente en la configuración de la tabla de rutas establecida por la aplicación. Estosmecanismos pueden combinarse para crear una topología dinámica, de modo que lared pueda descubrir nuevos caminos para enviar un mensaje si una ruta conocida oun nodo de paso caen momentáneamente.Estos mecanismos de integridad permiten a las redes ZigBee operar en un entornoaislado y protegido, incluso cuando hay otras redes ZigBee comunicándose por lamisma banda de frecuencia. Las redes ZigBee también pueden convivir con redes ba-sadas en otros estándares, tales como WiFi y Bluetooth, sin ver afectadas de formasignificativa sus prestaciones, aunque algunos estudios han demostrado que las pre-sencia de dispositivos Bluetooth sí pueden afectar estadísticamente al rendimientode las comunicaciones ZigBee, por su característica de salto adaptativo FHSS.

Establecimiento de red y enrutamiento Las redes ZigBee pueden configurarsepara adoptar una topología en Estrella, Árbol o Malla.

143

Capítulo 10 Normas y referencias

El estándar 802.15.4 establece la figura del nodo Coordinador de red, que desempeñauna función principal en el establecimiento de red y el enrutamiento de mensajes.En la topología en estrella, el Coordinador es el nodo central de la red, así como elnodo raíz en la topología en árbol.En la configuración de la red, afecta, además de la topología, la política de acceso y lavisibilidad de los mensajes para los nodos finales. Cuando hablamos de topología enZigBee, de forma implícita estamos hablando de las conexiones y el direccionamientode los nodos con característica FFD (implementan la versión completa de la pila deprotocolo 802.15.4), que se comportan en la red como Routers o como Coordinador.Estos dispositivos son los que van a registrar tablas de enrutamiento y los que puedencrear caminos y enlaces de red. Además de éstos, en ZigBee vamos a encontrardispositivos RFD (con una versión limitada de 802.15.4), que se comportan comodispositivos finales, van a conectarse a la red a través de los nodos que permitan suacceso y van a recibir los mensajes de difusión del dominio sólo si se habilita poraplicación.Para configurar la red ZigBee, necesitamos especificar los parámetros del esquema dedireccionamiento (CSKIP) y la política de acceso. La configuración afecta significa-tivamente a la propagación de los mensajes, de forma que, para ciertas aplicaciones,será más conveniente un envío basado en la información estática de rutas, mientrasque para otras será más provechoso el descubrimiento dinámico en cada envío.

Figura 10.2.: Parámetros de configuración de un árbol ZigBee

Seguridad Algunos mecanismos para prevenir la intrusión y la agresión externaen ZigBee son los siguientes:

Listas de control de acceso: utilizando listas, sólo los dispositivos marcadoscomo “amistosos” pueden conectarse a la red.Encriptación AES de 128-bits: la comunicación ZigBee puede encriptarse utili-zando este sistema basado en claves para impedir que un agente externo puedainterpretar los datos de la comunicación de red.

144

10.1 Normativa aplicada

Temporizadores de vida para los mensajes: mediante el uso de temporizadores,se previenen ataques de reenvío sobre la red. De este modo, se impide que undeterminado comando pueda ser copiado y reproducido, al haber vencido eltemporizador que lleva asociado.

Instalación y configuración Los dispositivos ZigBee son diseñados para participaren aplicaciones comerciales que van desde las instalaciones llave en mano hasta losproductos de fabricación en serie. De forma general, los sistemas ZigBee puedenpresentarse en tres modos de instalación distinto, según el grado de finalización yprotección de la configuración del dispositivo:

Sistemas preconfigurados: Todos los parámetros de operación son definidospor el fabricante. El sistema es utilizado tal y como se entrega y, por tanto, nopuede ser modificado ni ampliado. Ejemplos de este tipo podrían ser unidadesde vending o unidades de monitorización médica.Sistemas autoconfigurados: Los elementos de este tipo de sistema son confi-gurados e instalados por el usuario final. La red se prepara inicialmente paraenviar mensajes de descubrimiento entre dispositivos, garantizando así la pues-ta en servicio de la comunicación. A partir de este punto, se requiere de ciertaintervención por parte del usuario para programar los dispositivos; se habilitapara ello, por ejemplo, interruptores o pulsadores en el dispositivo con los queel usuario puede entrar y manejar el modo de programación. Una vez insta-lado, el sistema puede ser fácilmente modificado y ampliado sin necesidad dereconfiguración por parte del usuario; es el propio sistema el que detecta queun nuevo dispositivo ha sido añadido, eliminado o simplemente desplazado,ajustando de forma automática los parámetros de la aplicación.Sistemas custom: Son sistemas preparados para alojar una aplicación muyespecífica. Son diseñados e instalados por integradores de sistemas, utilizandodispositivos de red personalizados. Este tipo de sistemas se configuran por logeneral a través de una herramienta software y se entregan al usuario como unconjunto, de forma que el usuario sólo tiene acceso a las funciones de ajusteque el propio integrador deja visibles a través de las interfaces y mandos delsistema, pero nada más.

Profiles Con el propósito de uniformar las aplicaciones y garantizar la interopera-bilidad, la ZigBee Alliance introdujo en concepto de “profile” de dispositivo.Éste es un descriptor de las propiedades del dispositivo para un determinado casode uso. Hay dos clases de profiles, el Stack Profile y el Application Profile,que se describen a continuación.

Stack Profiles Incluyen aspectos de configuración de la red, tales como el tipoy forma, así como los parámetros visibles para la aplicación, como los niveles deseguridad.

145

Capítulo 10 Normas y referencias

Originalmente, la ZigBee Alliance definió tres stack profiles, orientados adiferentes mercados de aplicación:

Controles domésticos: pensados para uso en entornos domésticos. Aplicacio-nes típicas que podría soportar este profile incluyen iluminación, vigilancia,controles remotos, calefacción doméstica y HVAC.

Automatización de edificios: orientado a uso en edificios comerciales. Este tipode instalaciones deben integrar un mayor número de nodos, con varios nivelesde seguridad. Ejemplos de uso podrían ser seguridad del edificio, instalacionestécnicas, control de accesos y gestión central del edificio.

Control de plantas: diseñado para su uso en entornos industriales y automati-zación de producción.

Específico de la red: se trata de un profile genérico para su uso en situa-ciones en las que ninguno de los anteriores aporta una configuración adecuada;se aplica aquí una configuración establecida por el usuario. Este stackprofile suele utilizarse en conjunción con un profile de aplicación no público.

Application Profiles Un Application Profile se asocia a un determinadoStack Profile para responder a las necesidades de un determinado caso de uso oescenario. Por ejemplo, la ZigBee Alliance ha definido el profile de Control Domésticode Iluminación (HCL, por sus siglas en inglés); contiene los tipos de dispositivos yfunciones que son útiles para implementar un sistema domótico de iluminación,contando con interruptores, reguladores, detectores de presencia y balastros, entreotros aparatos.

La especificación ZigBee establece que cada profile queda identificado por un númerode 16-bits, dando así la posibilidad a definir un buen número de perfiles. Además,los profile pueden ser públicos o privados, según su propósito y alcance.

Públicos Los profile creados por la ZigBee Alliance son por definición públicos, yaque están pensados para su aprovechamiento por parte de los fabricantes ensoluciones de mercado que deben ser compatibles e interoperables. Por ejem-plo, el HCL permite que un fabricante cree un interruptor que pueda manejarun controlador de luz de otro fabricante. Los productos que implementan unprofile público deben pasar por un proceso de certificación para cuantificar sucompatibilidad, para garantizar qué funciones realiza conforme al profile. Co-mo podemos imaginar, la principal ventaja de estos descriptores es la libertadde mercado que garantiza.

Privados Debido a la gran variedad de segmetnos de mercado, regiones geográficasy categorías de productos que pueden aprovechar ZigBee, se asume que lamayoría de las aplicaciones van a comenzar por el desarrollo a partir de unprofile privado. Los productos que utilizan este tipo de perfiles mantienen todaslas características de conectividad ZigBee y pueden coexistir e interoperar con

146

10.1 Normativa aplicada

otras redes ZigBee, pero su dominio está restringido al alcance de su profileespecífico.Los profile privados tienen la ventaja para los fabricantes de servir comovehículo para introducir productos en mercados fuera de los profile públicos yles permiten diferenciar sus productos de otros dentro del mismo segmento demercado.La experiencia de uso de los profile de aplicación es que los de dominio públicoson demasiado amplios como para ser prácticos en una aplicación tan específicacomo el desarrollo del Soporte Técnico, por lo que se ha desarrollado un profileespecífico para el proyecto a partir de elementos generales de otros profile.

El nivel de aplicación2

Las características anteriores de despliegue y modelo lógico son manejadas por elnivel superior del estándar. El nivel de aplicación Zigbee consiste en la Subcapa deApoyo (APS), el contendor de Objetos de Dispositivo Zigbee (ZDO) y los compo-nentes de aplicación integrados por el desarrollador de los equipos.

Application Support Sub - Layer (APS) La Subcapa de Apoyo sirve de interfazentre la capa de Red y la capa de Aplicación, proveyendo una serie de serviciosque son invocados por los elementos superiores, tanto los del ZDO como por losobjetos de aplicación propios del desarrollador. Estos servicios son facilitados pordos entidades:

El agente de datos de APS (APSDE), a través de su punto de acceso APSDE-SAP. El APSDE facilita un medio de transmisión entre dos o más entidadesde aplicación alojadas en la misma red.El agente de gestión APS (APSME), a traves del APSME-SAP. EL APSMEprovee varios servicios, incluyendo funciones de seguridad y capacidades deasociación entre objetos. También se encarga de mantener una base de datosde los objetos registrados, denominada Base de Información del APS (AIB).

Application Framework (AF) El Framework de aplicación ZigBee es el entornoen el que los componentes de aplicación (las funciones programadas en el equipo)se alojan dentro de dispositivos ZigBee. Este mecanismo es el que las hace visiblesdentro de la Red y permite su explotación por otros dispositivos.Dentro de una misma aplicación, pueden definirse hasta 240 objetos distintos, cadauno identificado por un número de Endpoint entre el 1 y el 240. Además, se definenlos Endpoints especiales: el Endpoint 0 está reservado para la interfaz de datos delZDO, mientras que el 255 sirve como dirección de difusión para todos los objetosregistrados. Los Endpoints 241 - 254 permanecen reservados para un uso futuro.

2[?]

147

Capítulo 10 Normas y referencias

ZigBee Device Objects (ZDO) El ZigBee Device Objects (ZDO) ocupa un lugarfundamental en la construcción de las aplicaciones Zigbee, sirviendo como interfazentre los objetos del usuario, el profile del dispositivo y la capa APS. Formalmente,se situa entre los subniveles AF y APS, pero suele representarse como un bloqueparalelo al nivel de aplicación, con conexiones con todas las capas intermedias; estose debe a que el ZDO realiza tareas comunes para al sistema, como son:

Inicializar los niveles APS, NWK y el Proveedor de Servicios de Seguridad(SSP).Compactar toda la información de configuración de las aplicaciones finalespara determinar e implementar los mecanismos de descubrimiento, así comolas gestiones de seguridad, red y asociación.

Profiles y el nivel de aplicación3

Identificación de dispositivos y clusters El profile es la principal colección decaracterísticas de la aplicación. Cada profile define una colección de descriptores desus dispositivos y de los identificadores de los clusters soportados por la aplicación.A su vez, cada cluster puede soportar una lista de atributos, descritos por un valorde 16 - bits. Una parte fundamental del diseño de aplicaciones ZigBee pasa por lageneración de los descriptores de dispositivo, indentificación de clusters y organi-zación de atributos, ya que de ellos dependen las capacidades de intercambio entrenodos.Con el propósito de completar la definición de profiles de dominio público, la ZigBeeAlliance creó una librería de clusters (ZCL) que facilita una descripción común yuna enumeración de clusters y atributos de uso general. Esta librería se ha diseñadoespecíficamente para promer la reutilización de clusters y mantener la representaciónde los atributos de forma que sea posible un intercambio incluso entre dominios deprofile de aplicación distintos, con tal de que hayan heredado las característicasraíces de los atributos ZCL.Device descriptions and cluster identifiers must be accompanied by knowledge ofthe profile identifier to be processed. Prior to any messages being directed to adevice, it is assumed by the ZigBee protocol that service discovery has been emplo-yed to determine profile support on devices and endpoints. Likewise, the bindingprocess assumes similar service discovery and profile matching has occurred, sincethe resulting match is distilled to source address, source endpoint, cluster identifier,destination address, and destination endpoint.

Facilitando el Descubrimiento de Servicios Una vez que se ha creado un disposi-tivo compatible con un profile y se han identificado sus clusters de forma consistentecon la enumeración del profile, la aplicación de usuario puede desplegarse en la Red.

3[?]

148

10.1 Normativa aplicada

Para ello, cada componente de aplicación se asigna a un Endpoint concreto y seregistra por medio de un Descriptor Simple. El Descriptor Simple sirve como objetode referencia para los mecanismos de búsqueda, asociación entre dispositivos y pasode mensajes.

Descriptores Los dispositivos ZigBee se registran y presentan por medio de estruc-turas de descripción. Los datos contenidos en estos descriptores se concretan en ladefinición del dispositivo, por medio de elementos del Profile aplicado. El estándardefine cinco descriptores: Nodo, Potencia de nodo, Simple, Complejo y de Usuario.Descriptor de Nodo Contiene información acerca de las capacidades del nodo. Es

obligatorio y sólo puede haber un descriptor de este tipo por nodo.Potencia Ofrece un resumen dinámico de la alimentación y autonomía del nodo. Es

obligatorio y único.Descriptor Simple El Descriptor Simple contiene información específica de uno de

los Endpoints registrados en el nodo. Cada Endpoint debe registrar obligato-riamente un descriptor.

Cuadro 10.1.: Campos del Descriptor Simple

Descriptor Complejo Contiene información extendido de cada uno de los disposi-tivos contenidos en el nodo. El uso del descriptor complejo es opcional, perose presenta como una lista etiquetada en formato XML.

Descriptor de Usuario Contiene información que puede ayudar al usuario a iden-tificar el dispositivo, almacenando una cadena descriptiva del mismo, comopodría ser “TV del dormitorio” o “luces de escalera”. El uso del descriptor esopcional y el tamaño del campo descriptivo está limitado a 16 caracteres.

Descubrimiento por medio de descriptores El mecanismo de conexión utilizadoen el desarrollo del Soporte Técnico es el denominado “descubrimiento”. En él, la

149

Capítulo 10 Normas y referencias

información de un descriptor se solicita al agente ZDO, o bien se invoca una de-terminada operación que involucra a un Endpoint por su identificador o por lascaracterísticas de alguno de sus descriptores (fundamentalmente, el descriptor Sim-ple). Lógicamente, el Endpoint buscado puede estar alojado en un nodo remoto de lared, sirviendo entonces el ZDO como puerto de búsqueda y descubrimiento a travésde la red. Desde el punto y hora en que los componentes de aplicación siguen elmismo Profile de aplicación, es posible establecer una conexión entre dispositivossiempre que uno de los extremos sea capaz de descubrir a través del ZDO la ubica-ción de red de su extremo complementario. Podemos desplegar de esta forma todotipo de aplicaciones, involucrando escenarios de asociación 1 a 1, 1 a N o N a 1.

OSGi

We developed the OSGi technology to create a collaborative software envi-ronment. We were not looking for the possibility to run multiple applicationsin a single VM. Application servers do that already (though they were not yetaround when we started in 1998). No, our problem was harder. We wantedan application to emerge from putting together different reusable componentsthat had no a-priori knowledge of each other. Even harder, we wanted thatapplication to emerge from dynamically assembling a set of components. Forexample, you have a home server that is capable of managing your lights andappliances. A component could allow you to turn on and off the light over aweb page. Another component could allow you to control the appliances via amobile text message. The goal was to allow these other functions to be addedwithout requiring that the developers had intricate knowledge of each other andlet these components be added independently.

Ben McAffer

La OSGi Alliance4 es un consorcio independiente con la misión de “establecer unmercado para un middleware universal”. Se encarga de publicar especificaciones, im-plementaciones de referencia y suites de prueba en torno un sistema dinámico decomponentes para Java. Este sistema modular establece las bases de una “platafor-ma de servicios”, a partir de la cual es posible desarrollar aplicaciones modularestotalmente dinámicas y muy ligeramente acopladas. Al proceder del sector de aplica-ciones embebidas, OSGi conserva ese espíritu minimalista, basádose en un núcleo contan sólo 27 tipos de Java. Esta ética de simplicidad y consistencia está omnipresenteen la especificación OSGi, como podremos comprobar.

En pocas palabras, OSGi es una capa de modularidad que opera sobre la plata-forma Java. Ya hemos hablado antes del concepto “modularidad” en el Proyectocuando presentamos la Arquitectura Orientada a Servicio; en realidad, el conceptode modularidad proviene de mucho antes y es una constante en la evolución de los

4http://osgi.org

150

10.1 Normativa aplicada

paradigmas de desarrollo software y es ahora, a raíz de OSGi - entre otras platafor-mas - cuando está apareciendo por todas partes, en Spring, en la IDE Eclipse, en elservidor de aplicaciones GlassFish, etc, etc, etc.

Introducción

Las limitaciones de Java5 Para comprender la importancia de OSGi en la evolu-ción de la tecnología Java, tenemos que enteneder primero algunas limitaciones quepresenta Java a la hora de desarrollar aplicaciones modulares.

Java proporciona algunas características de modularidad a través de su orientacióna objeto, pero no está pensado para soportar una programación modular de granofino. Aunque no es justo criticar la tecnología Java por una característica fuera desu alcance, el éxito de Java ha supuesto un lastre para los desarrolladores que, a lalarga, han tenido que resolver por sus medios la necesidad de tener un mejor soportepara la modularidad.

Java dispone de un buen conjunto de modificadores de acceso para gestionar la vi-sibilidad del código, pero la aplicación de estos modificadores está dirigida a unaencapsulación de bajo nivel orientada a objeto, no a un sistema lógico de organiza-ción. En Java, la organización se resuelve por medio de “paquetes”, que se utilizande forma general para particionar el código. Para que una parte del código sea visibleentre dos paquetes Java, éste debe ser declarado como public (o protected, si seutiliza una herencia). En ocasiones, la estructura de una aplicación llama a códigoque pertenece a diferentes paquetes, lo que implica que todas las dependencias entrepaquetes deben exponerse como públicas, lo que las convierte en accesibles de formaglobal. A veces, esto puede dejar expuestos algunos aspectos de la implementación,suponiendo, a la larga, un problema de seguridad y escalabilidad del programa. Todoello implica que, al programar en Java, nos vemos regularmente obligados a decidirentre dos opciones:

Menoscabar la estructura lógica de la aplicación, englobando varias clases sinrelación en un mismo paquete para proteger la exposición de las APIs.

Mantener la estructura utilizando muchos paquetes, a costa de exponer algunasAPIs que no son públicas, por lo que pueden ser invocadas por clases en otrospaquetes.

Java también flaquea a la hora de instalar y mantener la aplicación. No hay una for-ma sencilla en Java para desplegar ordenadamente el conjunto apropiado de versio-nes de las dependencias y ejecutar la aplicación. Lo mismo ocurre cuando queremosrevisar la aplicación y sus componentes una vez que se ha sido instalada.

5[13]

151

Capítulo 10 Normas y referencias

Por qué OSGi6 OSGi sigue siendo Java, por lo que... ¿qué hace a OSGi ser mejorque Java? OSGi se apoya en los mismos mecanismos de Java, pero añade algunoselementos clave. Por ejemplo, en OSGi, en vez de hablar de JARs, hablamos deBundles. Un bundle se implementa por lo general como un JAR, pero añade unaidentidad e información de sus depedencias, de modo que un bundle es un JAR quese describe a sí mismo. Esta noción tan sencilla tiene dos efectos: a partir de ella,los productores y consumidores de un servicio tienen la oportunidad de exponer superspectiva del contrato de intercambio y, además, la entorno de ejecución tieneacceso a la información que requiere para aplicar sus prerrogativas.Por defecto, los paquetes de un bundle permanecen ocultos a otros. Los paquetesque contienen API deben ser expresamente exportados y, de forma complementaria,los bundles que utilizan una API deben importarla. Esta gestión de la visibilidades muy parecida en teoría a la de Java, pero a un nivel mucho más manejable yflexible. La plataforma OSGi refuerza las restricciones de acceso, estableciendo asílas bases para un sistema de componentes muy robustos pero, al mismo tiempo, muydébilmente acoplados. Esta característica, unida a la gestión en tiempo de ejecuciónde las dependencias, elimina el problema del Classpath Hell7, al tiempo que suponeuna mejora de rendimiento significativo en la carga de clases.Ciertamente, esta libertad tiene una contrapartida. En un sistema Java conven-cional, si queríamos utilizar una funcionalidad, tan sólo había que referenciar lostipos utilizados. Esta aproximación fuertemente cohesionada es más sencilla, peromuy limitada. En un escenario donde necesitamos más flexibilidad, este mecanismode importación simplemente no puede aplicarse. Como consecuencia, la comunidadJava se ha ido llenando de soluciones parciales para este problema: cargadores declases por contexto, buscadores de “servicios”, log appenders - todos ellos sonejemplos de mecanismos habilitados para facilitar la colaboración entre componentesdébilmente acoplados.El cambio que propone OSGi va más allá de la simple relación estática de impor-tación y exportación de paquetes. Para ello, se proponen los servicios como mediopara facilitar la colaboración dinámica. Un servicio es simplemente un objeto queimplementa un contrato, un type, que es registrado por medio del OSGi ServiceRegistry. Cualquier bundle que necesite utilizar un servicio solo tiene que importarel paquete que define el contrato y descubrir la implementación del servicio habilita-da en el registro de servicios. Lo revolucionario de este mecanismo es que el bundleconsumidor no conoce ningun detalle sobre el tipo que implementa este servicio niacerca del bundle que lo está proveyendo.OSGi es una de las primeras tecnologías en tener éxito con un sistema de componen-tes que realmente es capaz de resolver algunos de los problemas reales del desarrollo.En OSGi, el código resulta mucho más sencillo de escribir y probar, se favorece lareutilización de código, la construcción de sistemas se vuelve cualitativamente más

6[19]7http://stackoverflow.com/questions/373193/what-is-classpath-hell-and-is-was-it-really-a-problem-for-java

152

10.1 Normativa aplicada

sencilla, el despliegue es más manejable, los errores se detectan antes y el runtimefacilita una perspectiva completa del código en ejecución. Aún más importante, OS-Gi ha demostrado que funciona y así lo demuestra la adopción por parte de dosplataformas tan populares como Spring8 y Eclipse.

Resumen Técnico

OSGi es un conjunto de especificaciones que definen un sistema dinámico de com-ponentes para Java. Estas especificaciones permiten un modelo de desarrollo dondelas aplicaciones se organizan de forma dinámica a partir de diferentes componen-tes. OSGi permite a los componentes ocultar su implementación a la vista de otroscomponentes, al mismo tiempo que los pone en comunicación a través de servicios,que son objetos específicamente compartidos entre componentes. Este modelo tansencillo tiene consecuencias de largo alcance en todo el proceso de desarrollo, quecambia por completo con respecto a las tecnologías que lo preceden.

En muchos sentidos, OSGi puede considerarse una extensión al lenguaje Java queañade restricciones a la visibilidad y la dependencia de paquetes para que puedanser especificadas durante el desarrollo y aplicadas en tiempo de ejecución. A travésde estas nuevas características, resulta mucho más sencillo construir aplicaciones apartir de componentes muy cohesivos y débilmente acoplados.

Capas OSGi se organiza siguiendo un modelo por capas, como se presenta en lasiguiente figura.

Figura 10.3.: Capas de OSGi

Definimos a continuación estos elementos:

Bundles Los Bundles son los componentes de OSGi, producidos por los desarrolla-dores.

8http://www.springsource.org/

153

Capítulo 10 Normas y referencias

Servicios La capa de servicios conecta bundles de forma dinámica siguiendo unmodelo de publicación - búsqueda - asociación para objetos nativos de Java(POJOs).

Life-Cycle Es la API que constituye el ciclo de vida de los bundles. A partir de ella,pueden instalarse, iniciarse, parar, actualizarse o desinstalarse de la plataformade ejecución.

Módulos Esta capa define cómo exporta e importa el código un bundle.Seguridad Cubre los aspectos generales de seguridad de la plataforma.Entorno de ejecución Delimita los métodos y clases disponibles en un entorno o

plataforma de ejecución concreto.

Capa de Módulos La capa Modular da soporte al concepto de módulo en OSGi,que, como ya hemos comentado, se denomina bundle. Un bundle es un JAR conmetadatos (datos sobre datos), que contiene los archivos de clases y sus recursosasociados. Generalmente, una aplicación no se implementa en un único bundle, sinoque cada bundle es como módulo lógico que, combinado con otros, forma una apli-cación. Los bundles son más potentes que los archivos JAR generales porque puedendeclarar explícitamente cuáles de los paquetes que contiene son visibles externa-mente. De este modo, los bundles extienden los modificadores normales de acceso(public, private y protected) asociados al lenguaje Java.

Figura 10.4.: Anatomía de un bundle

Otra importante ventaja de los bundles sobre los JAR es que puede declararse explí-citamente qué paquetes externos debe importar. El gran beneficio de esta declaraciónes que el Framework OSGi puede gestionar y verificar la consistencia de todas lasdependencias del programa automáticamente; este procedimiento se denomina re-solución de bundles y supone un emparejamiento entre los paquetes exportados eimportados. La resolución de bundles garantiza la consistencia considerando tam-bién otros factores, como las diferentes versiones de un bundle o las condiciones dedespliegue de la aplicación.

Gestión del ciclo de vida La capa de Ciclo de vida controla cómo los bundles soninstalados y gestionados dinámicamente en el entorno OSGi. Usando un simil arqui-

154

10.1 Normativa aplicada

tectónico, la capa modular vendría a ser los cimientos y la estructura del edificio,mientras que la capa de ciclo de vida es el cableado eléctrico.La gestión del ciclo de vida tiene dos propósitos diferentes. Externamente a la aplica-ción, la capa define con precisión las operaciones relacionadas con el ciclo de vida deun bundle (instalar, actualizar, arrancar, parar y desinstalar). Estas acciones per-miten administar, gestionar y modificar de forma orgánica una aplicación de formacontrolada y efectiva. Esto implica que los bundles pueden ser incluidos o excluidosdel framework de forma segura, sin necesidad de reiniciar la aplicación ni perder sucoherencia.

Figura 10.5.: Ciclo de vida de un componente OSGi

Dentro de la aplicación, la gestión del ciclo de vida define cómo obtienen los bundlesel acceso al contexto de ejecución, lo que les facilita un medio de interacción con elentorno OSGi y las facilidades que suministra durante la ejecución. Esta aproxima-ción general a la gestión del ciclo de vida de la aplicaicón es muy potente, porquepermite crear aplicaciones que pueden ser gestionadas de forma externa y remota ocompletamente autónomas.

Capa de Servicios Por último, la Capa de Servicios soporta un modelo de progra-mación flexible, incorporando conceptos popularizados por la arquitectura orientadaa servicio (aunque ya pertenecían a OSGi antes de que SOA los hiciera famosos).La cuestión principal gira en torno al patrón de publicación, búsqueda y asociaciónorientado a servicios: una entidad proveedora de servicios publica sus servicios en unregistro, mientras que los clientes buscan en el registro para encontrar un servicioque les resulte útil. En este momento, la arquitectura SOA está fuertemente asociadaa los servicios web, pero los servicios en OSGi son locales y están confinados dentrode una máquina virtual, motivo por el cual suele referirse al modelo de servicios deOSGi como SOA dentro de una VM.La Capa de Servicios OSGi resulta muy intuitiva, porque facilita un desarrollo ba-sado en interfaces, considerado generalmente una de las mejores técnicas de progra-mación. Los Servicios OSGi son interfaces Java que representan un contrato teóricoentre un proveedor y un consumidor de servicio. Esto convierte a la capa de servi-cios en un nivel muy ligero, ya que los proveedores son sencillamente objetos Java,

155

Capítulo 10 Normas y referencias

accedidos mediante invocación de métodos. Adicionalmente, este modelo expande ladinámica basada en bundles de la capa Ciclo de Vida con una segunda dinámica ba-sada en servicios, ya que éstos pueden aparecer, proliferar y desaparecer en cualquiermomento de la ejecución. El resultado es un paradigma que evita las aproximacionesfrágiles y monolíticas del pasado, en favor de ser más modular y flexible.Estos conceptos se desarrollan con más detalle en las siguientes secciones.9

Servicios La principal razon por la que era necesario el modelo de servicio esporque Java demuestra cuán dificil es programar un modelo colaborativo sólo pormedio de la compartición de clases. La solución estándar de Java pasa por usar fac-torías, que emplean métodos estáticos y carga dinámica de clases. Por ejemplo, siqueríamos un DocumentBuilderFactory, se invocaba al método estático de la fac-toría DocumentBuilderFactory.newInstance(). Detrás de esta façade, el métodonewInstance podía intentar cualquier truco conocido (o inventado) para crear unainstancia de una subclase de DocumentBuilderFactory. En este modelo, tratar deinfluir en la implementación escogida no es trivial y generalmente afecta a toda laVM. Además, es un modelo pasivo; el código no puede hacer nada para advertir ladisponibilidad de un método, ni puede mostrar al usuario una lista para que esco-ja la implementación más adecuada. Tampoco es dinámico: una vez que se sueltala instancia, no puede retirarse ese objeto. Con todo, lo peor es que el mecanismofactoría es una convención aplicada en cientos de puntos de la VM, en los que cadafactoría contiene su propia API y sus mecanismos de configuración; no existe unagestión centralizada de las implementaciones a la que queda ligado nuestro código.La solución a todas estas cuestiones es el OSGi Service Registry. Un bundle pue-de crear un objeto y registrarlo con el service registry dentro de una o másinterfaces. Otros bundles pueden dirigirse al registro y sacar una lista de todoslos objetos que están registrados bajo una interfaz o clase concreta. Por ejemplo,un bundle provee una implementación del DocumentBuilder. Cuando arranca, creasu propia instancia de su DocumentBuilderFactoryImpl y la registra bajo la claseDocumentBuilderFactory. Entonces, un bundle que necesite una DocumentBuilderFactorypuede ir al registro y preguntar por todos los servicios que extiendan la claseDocumentBuilderFactory. Y, lo que es aún mejor, un bundle puede esperar a queaparezca un determinado servicio para tratar de conectar con él.En resumen, un bundle puede registrar un servicio, puede obtenerlo del registro ypuede permanecer a la escucha hasta que aparezca un servicio. Un número indeter-minado de bundles pueden registrar el mismo tipo de servicio y cualquier cantidadde bundles pueden obtener el mismo servicio. Este modelo lógico queda reflejado enla siguiente figura:Los servicios son elementos dinámicos. Esto implica que el bundle propietario pue-de eliminar el servicio del registro mientras está siendo utilizado por otros bundles.

9[13]

156

10.1 Normativa aplicada

Figura 10.6.: Modelo de servicio de OSGi

En esta situación, los bundles consumidores deben asegurarse de que no usan másel objeto de servicio, eliminando topas las referencias al mismo. Aunque esta ges-tión puede parecer muy compleja, la realidad es que disponemos de mecanismosy técnicas que simplifican la implementación y facilitan la tarea del desarrollador.La dinámica de servicios se incorpora para permitir que los bundles se instalen ydesinstalen bajo demanda y los demás bundles puedan adaptarse. Sin embargo, unode los mayores descubrimientos de OSGi es que muchas situaciones reales puedenmodelarse y controlarse mucho mejor por medio de servicios dinámicos. Por ejem-plo, un Device service puede representar a un dispositivo en una red local. Si estedispositivo desaparece de la red, el servicio que lo representa se borra del registro.De este modo, la disponibilidad del servicio modela la existencia de una entidad delmundo real dentro de la plataforma. Este mecanismo es muy útil cuando - comoocurre en el Soporte Técnico - aplicamos un modelo distribuido en el que un serviciodebe abortarse si se pierde la conexión a una máquina remota. La dinamización deservicios también resuelve el problema de la inicialización: en una aplicación OSGibien diseñada, no es necesario mantener un orden de arranque específico entre losbundles.

Despliegue Los bundles se despliegan en un framework OSGi; éste es su entorno deejecución. No se trata de un contenedor, como los Java Application Servers, sino deun entorno puramente colaborativo. Los bundles corren en la misma VM y puedencompartir efectivamente recursos de código. El framework utiliza los mecanismosde importación / exportación para interconectar los bundles de tal modo que notengan que preocuparse de la carga de clases. Otra diferencia con respecto a losservidores de aplicación es que la gestión de la plataforma está reglada. Una únicaAPI muy simple permite arrancar, instalar, parar y actualizar cualquier bundle, asícomo acceder a una lista de los bundles desplegados y su conexión con servicios.

Implementaciones The OSGi specification process requires a reference implemen-tation for each specification. However, since the first specifications there have alwaysbeen commercial companies that have implemented the specifications as well as opensource implementations. Currently, there are 4 open source implementations of the

157

Capítulo 10 Normas y referencias

framework and too many to count implementations of the OSGi services. The opensoftware industry has discovered OSGi technology and more and more projects de-liver their artifacts as bundles.

Resumen

El framework OSGi se compone de capas que se apoyan sobre un entorno Java,cambiando el paradigma de desarrollo de aplicación, de forma que, con OSGi:

La aplicación se diseña descomponiéndola en interfaces de servicio y clientesde estas interfaces.

Los componentes proveedores y clientes pueden implementarse utilizando cual-quier práctica y herramienta.

Los componentes cliente y proveedor suelen empaquetarse en archivos JARseparados, a los que se incorpora una serie de metadata propia de OSGi.

Las especificaciones OSGi definen un modelo de componentes maduro y exhausti-vo con una API eficaz y significativamente pequeña. Por lo general, la migraciónde sistemas basados en plugins monolíticos o de cosecha propia consiguen grandesmejoras en todo el proceso de desarrollo software.

La principal razon por la que la tecnología OSGi es tan exitosa es porque suministraun sistema de componentes que realmente funciona en un número sorprendente deentornos profesionales. El sistema OSGi participa en la construcción de aplicacióntan complejas como IDEs (como Eclipse), servidores de aplicación (GlassFish, IBMWebsphere, Oracle/BEA Weblogic, Jonas, JBoss), entornos de aplicación (Spring,Guice), automatización industrial, pasarelas residenciales, teléfonos y mucho más.

Las especificaciones comenzaron a redactarse en 1998 y estaban incialmente dirigidasal mercado de la domótica, tratando de solventar el problema de cómo desarrollaraplicaciones que fueran independientes de los componentes eléctricos instalados. Enla última década, la industria software ha cambiado fundamentalmente por la irrup-ción de los proyectos en código abierto, de

The OSGi specifications were started in 1998 and were intended for the home auto-mation market, trying to solve the problem how to build applications out of indepen-dent components. In the this past decade, the software industry was fundamentallychanged because of the explosion in open source projects. Ten years ago, an appli-cation consisted mostly of specifically written code. Today, most software is largelywiring up open source artifacts that were often not designed to work together. Thisis similar to the problem that OSGi was designed to solve. Many open source pro-jects are therefore adopting the OSGi specifications because they see that they canfocus on the real problem and worry less about infrastructure, as well as becomingeasier to use in other projects. This trend is accelerating.

158

10.1 Normativa aplicada

UPnP

La tecnología UPnP define una arquitectura para la conectividad punto - a - puntode aplicaciones inteligentes, dispositivos inalámbricos y PCs de todo tipo. Ha sidodiseñada para proporcionar facilidad de uso, flexibilidad y conectividad uniforme enredes ad-hoc o con mínima gestión, tanto en el hogar y la pequeña oficina, como enespacios públicos como conectados a través de Internet.

UPnP es una tecnología conocida y abordada con anterioridad en trabajos acadé-micos del Departamento de Ingeniería de Sistemas y Automática. Una presentaciónmuy detallada de la torre de protocolos UPnP, así como de sus mecanismos de co-municación, puede encontrarse en el excelente trabajo de Rafael Borja Pozo10. Parasu aplicación en el desarrollo del Soporte Técnico, nos limitaremos a una introduc-ción al estándar para comprender su estructura y las estrategias de integración conOSGi.

Resumen técnico

Universal Plug and Play (UPnP) es más que una simple extensión del modelo deperiféricos Plug and Play. Fue diseñado para soportar configuración cero, conecti-vidad transparente y descubrimiento automático para una variedad muy amplia dedispositivos, con una gran libertad de mercado. Mediante UPnP, un equipo pue-de contectarse a una red, obtener una dirección IP, transmitir sus capacidades ydetectar la presencia de otros dispositivos, con sus prestaciones, de forma automá-tica. A partir de este descubrimiento, los dispositivos pueden comunicarse entre sídirectamente, habilitando así un intercambio entre pares.

UPnP se apoya en la torre de protocolos TCP / IP, lo que permite al estándar adap-tarse sin problemas a toda clase de redes. Las tecnologías incrustadas en la torreUPnP incluyen estándares de Internet como IP, TCP, UDP, HTTP y XML. Comoen los servicios Web, los contratos entre dispositivos se apoyan en protocolos de co-nexión declarativos, expresados en transacciones XML y comunicados vía HTTP. Altratarse de una arquitectura de red abierta y distribuida, definida por los protocolosen uso, es independiente del sistema operativo, lenguaje de implementación o mediode soporte. UPnP no especifica una API, permitiendo a cada desarrollador producirsu propia librería de acuerdo con las necesidades de sus clientes.

Componentes de una red UPnP

Los bloques constructivos básicos de una red UPnP son tres: Dispositivos, Serviciosy Puntos de Control (ControlPoints). Los describimos a continuación.10Control e integración del robot de servicios ROVIO bajo el estándar UPnP, Rafael

Borja Pozo, 2011. D PT.l954 Compacto.

159

Capítulo 10 Normas y referencias

Figura 10.7.: Esquema de componentes UPnP

Dispositivo Un Dispositivo UPnP es un contenedor de Servicios y otros dispositivosanidados. Un VCR UPnP, por ejemplo, podría descomponerse en un servicio detransporte de vídeo analógico, un servicio de control ( tuner) y un servicio dereloj.

Los dispositivos advierten de su presencia a la red, publicando total o parcialmentesu descriptor de dispositivo. Un descriptor contiene el detalle lógico del dispositivo,expresado formalmente por medio de un documento XML que responde a la cumpli-mentación por parte del fabricante de una plantilla UPnP de dispositivo, incluyendodatos del modelo, número de serie, detalles gráficos y enlaces URL a sus mecanismosde control, anuncio y presentación.

Servicios Los Servicios son la unidad mínima de control en una red UPnP. UnServicio expone acciones a la red y captura su estado a través de Variables de Estado.Al igual que ocurre con los dispositivos, la descripción del servicio es parte de unaplantilla XML estándar, definida por el UPnP Forum. Para referirse a los servicios,se incluyen los punteros URL a los descriptores públicos dentro del documento deDispositivo.

Un servicio UPnP dentro de un dispositivo puede modelarse como una tabla deestado, un servidor de control y un servidor de eventos. La tabla de estados capturael estado del servicio en variables que se van actualizando con los cambios del mismo.El servidor de control recibe las solicitudes de acción, las ejecuta, actualiza el vectorde estados del servicio y devuelve las respuestas pertinentes. Por su parte, el servidorde eventos publica a través de la red cualquier cambio en la tabla de estados delservicio a las entidades suscritas.

160

10.1 Normativa aplicada

El desarrollo y la implantación de la tecnología ha facilitado la creación de unaclasificación complementaria al estándar de los dispositivos y protocolos de controlcanónicos para UPnP. La lista incluye dispositivos AV, así como servicios de gestión,configuración, gestión de contenido y calidad de servicio. Hay disponible un catálogocompleto en la página web del UPnP Forum11.

Control Points Un punto de control de una red UPnP es un agente capaz de descu-brir y tomar el control de otros dispositivos. Tras el descubrimiento, un ControlPointpuede realizar las siguientes acciones:

• Recabar el descriptor de Dispositivo y obtener una lista de sus Servicios asociados.

• Obtener los descriptores de Servicio.

• Tomar el control de un servicio.

• Suscribirse al origen de eventos del servicio, de forma que reciba una notificaciónde cualquier cambio en el mismo.

Figura 10.8.: Secuencia de diálogo Dispositivo - ControlPoint

UPnP AV Standard

La arquitectura UPnP AV define la interacción entre ControlPoints UPnP y Disposi-tivos UPnP AV. Como el resto del estándar, es independiente del tipo de dispositivo,formato de contenido y protocolo de transferencia de datos. Soporta una amplia va-riedad de equipos, incluyendo desde TVs y settop boxes hasta camcoders, EPFs y,por supuesto, aplicaciones PC. Respecto a los contenidos, la arquitectura permi-te distintos formatos de imagen y vídeo (MPEG2, MPEG4, JPEG, MP3, WMA,NTSC, PAL...), asú como distintos mecanismos de transmisión (IEEE-1394, HTTPGET y PUT/POST, RTP, etc.).

UPnP AV fue creado para cubrir los siguientes objetivos:

Soportar cualquier protocolo de transferencia y formato de contenido.11http://upnp.org/sdcps-and-certification/standards/sdcps/

161

Capítulo 10 Normas y referencias

Permitir que el contenido AV fluya directamente entre dispositivos, sin inter-vención del CP.Permitir que el CP permanezca al margen del protocolo y formato de datos,facilitando una gestión transparente.Escalabilidad del sistema, admitiendo tanto dispositivos con capacidad limi-tada como dispositivos completos.Capacidad de playback sincronizado a varios dispositivos de salida.Control de acceso, Protección de Contenido y Gestión de Derechos Digitales.

Modelo de 2 cajas: ControlPoint con contenido En el escenario planteado en lafigura a continuación, se han combinado en un mismo equipo la función de servidorde contenido de un MediaServer y la función de gestión del ControlPoint, de tal formaque el dispositivo usuario (MediaRenderer) contecta con la UI del ControlPoint paralocalizar y seleccionar el contenido que quiere mostrar.De los casos de uso planteados por el estándar UPnP AV, es el que resume y con-centra mejor las funciones de los equipos desplegados en el Soporte Técnico, ya quecentraliza naturalmente la gestión en el equipo Servidor y permite que cada clientereproductor solicite el contenido adecuado para su reproducción. Esta arquitectura(control y contenido central, reproducción distribuida), permite tanto un modelode operación aislada de cada reproductor como un modelo de reproducción coordi-nada, pudiendo simplificarse además si consideramos que el contenido se encuentraregistrado en el ControlPoint (en un índice o una lista de reproducción), pero es-tá físicamente ubicado en el mismo equipo MediaRenderer, con lo cual todas lastransacciones fuera de UPnP pueden producirse sin salir a la red.

Figura 10.9.: Modelo de 2 cajas de UPnP AV: Control Point + Contenido en unmismo nodo

162

10.1 Normativa aplicada

Desarrollo UPnP

De lo que hemos visto hasta ahora, podemos deducir que el alcance del estándarUPnP no cubre la implementación en uno u otro lenguaje o entorno. A medida queha madurado la tecnología, han ido apareciendo kits de desarrollo para la progra-mación de dispositivos y servicios en UPnP; el propio Forum mantiene una lista deimplementaciones realizadas tanto por miembros como de distribuciones en códigoabierto12, dentro de las cuales encontramos la librería SDK Cling para Java, de laque ya hemos hablando anteriormente.

UPnP y OSGi La UPnP Device Service Specification en la Release 4 deOSGi establece un mecanismo de puente entre los protocolos UPnP y la arquitec-tura orientada a servicio de OSGi. Básicamente, este puente se plantea como unaocultación de los protocolos UPnP dentro de una API, de modo que los Control-Point UPnP pueden ser importados como bundles OSGi y, complementariamente,un servicio OSGi pueden exportarse como un dispositivo UPnP.Estos mecanismos han sido explorados y aprovechados en las soluciones de inter-operabilidad de los dos primeros apartados en laSección 15.5. Aplicado al escenarioAV, se trataría de aprovechar una implementación del UPnP Device Service (porejemplo, la de Cling), para utilizar los mecanismos de conexión de OSGi comopunto de control para los dispositivos MediaRenderer detectados en red o, comple-mentariamente, crear un ControlPoint desde OSGi que pueda conectarse a la redUPnP.Una segunda vía de interoperabilidad es planteada por André Bottaro en 200713

y consistiría en un mapeado directo entre los elementos descriptivos XML de lasentidades UDA a objetos residentes en OSGi. Este mapeado podría ser automatizadopor medio de un generador de código, ya que la arquitectura comparada de serviciosen UPnP y OSGi revela una fuerte correlación entre ambas, salvo por el hecho deque la descripción de las variables de estado en XML no guarda ninguna equivalenciaen OSGi.Esta idea ya ha sido explotada con éxito anteriormente. La aproximación típicapara resolver los mecanismos de descubrimiento, descripción, control y eventos enun entorno de programación orientada a objeto pasaba por el uso de Generadores deDispositivos, como el propuesto por Intel para C/C++. Esta herramienta realiza unmapeo entre descriptores XML UPnP y su API de programación, de tal forma que,a partir de un descriptor de dispositivo XML, se generan una serie de fragmentos decódigo correspondientes a los servicios y dispositivos recogidos. En la misma línea,se han propuesto varios generadores de dispositivos UPnP para OSGi, como porejemplo los de la Universidad de Grenoble14 y Didier Donsez15, INRIA en el proyecto12http://upnp.org/sdcps-and-certification/resources/sdks/13RFP72 - Extended Mapping for UPnP Discovery Transparency14http://adele.imag.fr/index.php/projects15http://membres-liglab.imag.fr/donsez/dev/osgi/upnpgendevice/readme.html

163

Capítulo 10 Normas y referencias

Amigo IST 16 o el Siemens AG en el proyecto ePerSpace IST 17. Esta aproximación,no obstante, plantea un modelo no estandarizado, ya que, a partir de esta traducción,los clientes de servicio pasan a depender de los fragmentos generados de código; nopuede recuperarse la descripción XML a partir del código, por lo que el descriptordebe ser proporcionado con anterioridad, en su propio formato.

10.2. Programas de cálculo y diseño

Para el desarrollo del Soporte Técnico, no se han precisado herramientas de cálculoavanzado ni herramientas de diseño asistido. Las bases teóricas del proyecto se hanextraido de la investigación bibliográfica y el diseño es una aplicación de la informa-ción técnica recogida; los parámetros de ajuste necesarios para la configuración delos elementos de la instalación de referencia se han escogido siguiendo criterios razo-nados y reglas muy sencillas; en la mayoría, hablamos de valores que se han ajustadoa partir de un valor inicial seleccionado de alguna tabla de consulta o plantilla.

En los Anexos del Proyecto, se presentan las bases teóricas del proyecto, que cu-bren aspectos de modelado del movimiento y consideraciones sobre la propagaciónen interiores y su efecto sobre la función de localización y seguimiento del visitan-te. Sobre estos elementos, se desarrollan en una segunda parte los parámetros derendimiento que definen al sistema, tanto en su organización temporal como en susniveles de funcionalidad; haremos especial hincapié, en esta última parte, en los as-pectos de protocolo y arquitectura de comunicaciones, al ser fundamentales para lacaracterización global del Soporte Técnico.

Respecto al diseño, al tratarse de un proyecto eminentemente software, se ha recurri-do a herramientas específicas para el modelado gráfico de los componentes softwaredel sistema. La herramientas empleadas en la fase de concepción y en la revisióndocumental del proyecto han sido, fundamentalmente Enterprise Architect (SPARXSystems) para los diagramas UML y Microsoft Visio para la definición de boce-tos y diagramas específicos. Merece también una mención, por su aportación en laracionalización inicial del problema, la utilidad FreeMind en el diseño de mapas con-ceptuales. Para el desarrollo de código, diferenciamos los bloques WSN y la parteServidor - Red UPnP del sistema: la primera parte del Soporte Técnico - corres-pondiente a ZigBee - se ha desarrollado íntegramente en el IDE Code::Blocks conla librería de desarrollo de Jennic necesaria para la programación de los motes deprueba; la segunda parte - hecha en OSGi y UPnP - se ha realizado en la versiónIndigo de la IDE Eclipse Equinox, con los complementos y librerías según necesidad,conforme a la arquitectura de referencia. Todos los elementos de descripción de laarquitectura y el protocolo están en formato literal u organizados en tablas, por loque tampoco para esta faceta se han precisado soluciones más específicas.16http://www.ist-eperspace.org/17http://www.hitech-projects.com/euprojects/amigo/deliverables.htm

164

10.3 Entorno de Desarrollo

10.3. Entorno de Desarrollo

IDE Eclipse RCP Indigo (3.6)

Eclipse es un entorno de desarrollo integrado de código abierto multiplataformapara desarrollar "Aplicaciones Enriquecidas de Cliente", opuestas a las aplicaciones"Cliente-ligero", pensadas para navegadores.

Eclipse es ahora desarrollado por la Fundación Eclipse, una organización indepen-diente sin ánimo de lucro que fomenta una comunidad de código abierto y un con-junto de productos complementarios, capacidades y servicios. Eclipse fue liberadooriginalmente bajo la Common Public License, pero después fue re-licenciado bajola Eclipse Public License.

Arquitectura La base para Eclipse es la Plataforma de cliente enriquecido (delInglés Rich Client Platform RCP). Los siguientes componentes constituyen la pla-taforma de cliente enriquecido:

Plataforma principal - inicio de Eclipse, ejecución de plugins

OSGi Equinox - una plataforma para bundling estándar.

El Standard Widget Toolkit (SWT) - Un widget toolkit portable.

JFace - manejo de archivos, manejo de texto, editores de texto

El Workbench de Eclipse - vistas, editores, perspectivas, asistentes

El entorno de desarrollo integrado (IDE) de Eclipse emplea módulos (en inglés plug-in) para proporcionar toda su funcionalidad al frente de la plataforma de clienteenriquecido, a diferencia de otros entornos monolíticos donde las funcionalidadesestán todas incluidas, las necesite el usuario o no. Este mecanismo de módulos esuna plataforma ligera para componentes de software. Adicionalmente a permitirlea Eclipse extenderse usando otros lenguajes de programación como son C/C++ yPython, permite a Eclipse trabajar con lenguajes para procesado de texto comoLATEX, aplicaciones en red como Telnet y Sistema de gestión de base de datos. Laarquitectura plugin permite escribir cualquier extensión deseada en el ambiente,como sería Gestión de la configuración. Se provee soporte para Java y CVS enel SDK de Eclipse. Y no tiene por qué ser usado únicamente para soportar otroslenguajes de programación.

La definición que da el proyecto Eclipse acerca de su software es: "una especie deherramienta universal - un IDE abierto y extensible para todo y nada en particular".

La elección de Eclipse como entorno de desarrollo, frente a otras implementacionesdel estándar OSGi - como Knoplerfish o Felix, es consecuencia del itinerario deaprendizaje seguido en los preliminares del proyecto, ya que toda la documentaciónestaba referida a Eclipse como entorno de ejercicio.

165

Capítulo 10 Normas y referencias

IDE Code::Blocks

Code::Blocks es un entorno de desarrollo integrado libre y multiplataforma para eldesarrollo de programas en lenguaje C y C++. Está basado en la plataforma deinterfaces gráficas WxWidgets, lo cual quiere decir que puede usarse libremente endiversos sistemas operativos, y está licenciado bajo la Licencia pública general deGNU.Jennic Ltd distribuye una versión de Code::Blocks configurada para trabajar consus microcontroladores, incluyendo un compilador propio, un depurador en línea,una aplicación de transferencia de código y su plataforma de desarrollo y libreríascomplementarias. Por este motivo, era la elección natural para el desarrollo de laparte WSN del Proyecto.

Kit de desarrollo Jennic JN5139

Para la programación del prototipo del sistema se han empleado los equipos delkit de desarrollo JN5139v1 de Jennic, del año 2007. Estos equipos vienen con unchip ZigBee 2004 (versión Estándar) con un transceptor radio en banda 2,4GHz. Laprogramación de los dispositivos es en código C, utilizando para ello la herramientade desarrollo de Jennic, que incluye:

Software de la pila de protocolo IEEE 802.15.4.JenNet Network Stack (alternativa a ZigBee propia de Jennic).Jenie API (alternativa al nivel AF de ZigBee de Jennic).ZigBee 2004 Networking Stack.

166