Arquitectura

La figura 3.2 muestra la arquitectura propuesta para el middleware que soporta el es- quema de cooperación Smart TV - Smartphone. Como se puede observar, la arquitectura incluye una estructura en capas que evita el acoplamiento entre los principales compo- nentes del sistema, al tiempo que facilita su mantenimiento y evolución sobre el tiempo. En términos generales, la capa inferior es soportada por el sistema operativo Android, es- pecialmente en lo que se refiere a las capacidades de networking. Por otro lado, la capa superior despliega una API abierta que facilita el acceso a los servicios del middleware de una forma simple al abstraer las complejidades del modelo de comunicación y transferencia de mensajes. A continuación se realizará una breve descripción de cada una de las capas de la arquitectura.

Midddleware Core Layer WebSocket Layer WAMP Layer Message Processor Interaction Decoder Interaction Encoder Open API Event Reporter Android App 1 Android App 2 Android App 3 Android OS

Figura 3.2:Arquitectura del middleware.Fuente Propia.

3.3.3.1. WebSocket layer

Se implementa una versión liviana del protocol WebSocket con el objeto de lograr una comunicación bidireccional en tiempo real entre los Smartphones y el Smart TV. Actual- mente, varios intentos para propocionar comunicación en tiempo real sobre protocolos de Internet confían en técnicas no estandarizadas conocidas como Comet [117], las cuales se implementan sobre un protocolo sin estado como HTTP (el término sin estado hace referen- cia a que cada solicitud en HTTP es independiente una de la otra). Algunas de ellas como Polling, Long Polling o Streaming posponen la respuesta HTTP hasta que el servidor tiene algo para enviar hacia el cliente, dando la apariencia de una comunicación en tiempo real [118]. No obstante, este tipo de técnicas incrementan la sobrecarga de mensajes y por ende generan mayores niveles de latencia, lo cual restringe su aplicación en el desarrollo de un middleware con propósitos interactivos de acuerdo a los principios expuestos en la sección 3.3.1.

En su lugar, el protocolo WebSocket proporciona una comunicación full-dúplex a través de un canal de comnunicaciones bidireccional que opera a través de un socket abierto sobre la Web, una característica deseable para construir sistemas escalables con requerimientos de baja latencia como es el caso del middleware propuesto [119]. Al reducir la sobrecar- ga de mensajes, la capa WebSocket proporciona un canal de comunicaciones bidireccional eficiente entre los diferentes dispositivos.

3.3.3.2. WAMP layer

La propuesta de implementación presentada en esta arquitectura puede definirse como un middleware orientado a mensajes (MOM) que utiliza un paradigma de interacción Pu- blisher/Subscriber. MOM es un tipo específico de middleware que soporta el intercambio de mensajes a través de un ambiente de aplicación distribuido; algunos de ellos aseguran la entrega de mensajes a través de gestión de colas y proporcionan servicios de soporte (di- rectorio, seguridad, etc.). Por otro lado, el modelo Publisher/Subscriber es una paradigma popular de interacción en el cual el Publisher publica un mensaje a muchos consumidores a través de un canal virtual llamadotopic otópico. Así, los consumidores eligen un tópico de su interés y se suscriben al mismo, de tal manera que cualquier mensaje correspondiente a un tópico específico es entregado a todos sus suscriptores [120].

De acuerdo a la descripción realizada previamente, esta capa gestiona todas las comple- jidades relacionadas con el intercambio de mensajes usando un esquema de interacción Publisher/Subscriber. Con este propósito, se adoptó una implementación open source pa- ra Android del protocolo WAMP (Web Application Message Protocol), la cual fue adaptada para mejorar sus estabilidad [121]. Este protocolo, corresponde a una abstracción de al- to nivel del protocolo WebSocket, lo cual garantiza que el intercambio de mensajes entre Publishers y Subscribers sea realmente asíncrónico, al tiempo que mejora la eficiencia en la notificación de eventos hacia los Subscribers gracias a la reducción en la sobrecarga de mensajes que ofrece el protocolo como fue analizado previamente. El esquema de interac- ción será desglosado con mayor detalle cuando se presente el modelo de comunicaciones en la sección 3.3.4.

3.3.3.3. Middleware core layer layer

Esta capa actúa como una gateway para el intercambio de mensajes y gestiona el pro- ceso de interacción de acuerdo a un modelo de comunicaciones bien definido. En términos simples, las acciones de los usuarios sobre las pantallas táctiles de los Smartphones son preprocesadas y luego preparadas en un formato específico de mensajes que son enviados a otros dispositivos. Igualmente, los mensajes entrantes son procesados y entregados a la aplicación correspondiente en el Smart TV a través de los servicios del API.

Específicamente, las funciones de esta capa se soportan en componentes más especiliza- dos que se describen a continuación:

Interaction Encoder:Todos los eventos que tienen lugar en las pantallas táctiles de los Smartphones requieren de una apropiada codificación antes de ser publicados en el Smart TV, la cual es la principal función de este componente. En sentido estricto, las aplicaciones de los dispostivos móviles sensan los eventos y gestos que se producen en la pantalla, los cuales a su vez disparan eventos táctiles en el sistema tales como press, long press, tap, double tap, swipe, drag, move o un evento táctil personalizado.

Message Processor: Este componente es responsable del envío y recepción de los mensajes que intercambian los dispositivos a través del WAMP Broker. En términos generales, los eventos táctiles codificados son publicados en lostopics correspondien- tes; posteriormente, el WAMP Broker define el destino final de los mensajes de acuer- do a los suscriptores existentes en lostopics. Finalmente, este componente recibe los mensajes entrantes de forma codificada y los entrega al Interaction Decoder.

Interaction Decoder:Este componente es responsable de la decodificación de todos los mensajes entrantes con el objeto de reconstruir apropiadamente la información del evento táctil original. Los eventos táctiles reconstruidos son entregados a las aplica- ciones de terceros a través de los métodos de notificación disponibles en la API del middleware.

Event Reporter: Este componente es responsable de la recolección de información relacionada con la ejecución de los procesos del middleware y las interacciones rea- lizadas por los usuarios. La información de ejecución del middleware se refiere a los datos del comportamiento en tiempo de ejecución como alertas, advertencias, errores o bloqueos de los componentes en las distintas capas que pueden ser relevantes pa- ra los desarrolladores de aplicaciones. La información de las interacciones realizadas por los usuarios se refiere a los mensajes de interacción que se están intercambiando, la cantidad de usuarios que interactúan y la forma en que lo hacen. Estas funciones fueron concebidas con propósitos de gestión para un entorno de digital signage. Por ejemplo, a través de esta información se podría inferir el grado de aceptación de una campaña publicitaria o el set de anuncios preferido por los consumidores de un centro comercial.

3.3.3.4. Open API

El middleware expone una API abierta para proporcionar acceso a sus servicios a los desarrolladores de aplicaciones. Esta API abstrae las complejidades realacionadas con el modelo de comunicaciones implementado. Específicamente, en el diseño y construcción del API se utilizaron un conjunto de patrones reconocidos en la industria del software [122], tales como:

Factory:Permite la creación de instancias de mensajes o de clientes de comunicación.

Observer:Habilita la notificación de eventos relacionados con el estado de las cone- xiones, el intercambio de información y el control de los dispositivos.

Singleton:Facilita la identificación de las interacciones de los usuarios sobre la pan- talla de los Smartphones.

Es importante resaltar que de acuerdo a las restricciones analizadas en la sección 3.3.2, el diseño del API no contempla la implementación de widgets adicionales a los ya existentes en el sistema operativo Android. En este orden de ideas, el principal propósito del API consiste en la abstracción de los procesos de los componentes de las capas inferiores del middleware, especialmente en lo correspondiente al modelo de comunicaciones.

La figura 3.3 muestra un diagrama de clases de alto nivel que ilustra las principales fun- cionalidades proporcionadas por el API. A continuación, se realiza una breve descripción de las clases e interfaces principales:

Figura 3.3:Middleware API.Fuente Propia.

Client:Corresponde a la clase principal que habilita un punto de entrada para estable- cer una conexión con el WAMP Broker. Así mismo, soporta los procesos de publicación y suscripción a los diferentes tópicos.

ClientFactory: A través de la implementación del patrón Factory habilita la creación de objetosClient de acuerdo a parámetros específicos.

ConnectionHandler: Esta interface define métodos de callback para gestionar las notificaciones acerca de eventos de conexión hacia el WAMP Broker.

EventHandler:Esta interface define métodos decallback para gestionar las notifica- ciones acerca de eventos de interacción sobre las pantallas táctiles de los Smartpho- nes.

ControlHandler:Esta interface define métodos decallback para gestionar las notifi- caciones acerca de eventos de control desde los Publishers y los Subscribers.

FeedbackHandler: Esta interface define métodos decallback para gestionar las no- tificaciones acerca de eventos publicados en el tópico de Feedback. A través de este tópico se habilita la entrega de información complementaria a los suscriptores de un tópico particular.

Message:Esta clase encapsula la estructura del contenido de los mensajes intercam- biados entre losClients (Publishers/Subscribers) y el WAMP Broker.

MessageFactory: A través de la implementación del patrón Factory habilita la crea- ción de objetosMessagede acuerdo a parámetros específicos.