cessários ao sistema quando um dispositivo deixa a rede. O Device Network Manager vai re-organizar dispositivos que estivessem conectados ao dispositivo que saiu, disparando exceções quando algum método de um dispositivo morto tentar ser acessado.
5.3
Comunicando o lado do telespectador com a arquite-
tura
O sistema apresentado nesse trabalho objetiva possibilitar aplicações de TV digital se comunicarem, receberem informações e monitorar Dispositivos de Interação no cená- rio de programas de TV ao vivo. Porém essas aplicações são comumente desenvolvidas para um middlware de TV especifico, como o MHP, Open TV, Ginga, etc. Para permitir aplicações de TV se comunicarem com os Dispositivos de Interação de forma mais trans- parente em relação ao middleware que esteja executando no receptor do telespectador, desenvolvemos um middleware-aplicação chamado Interactive Device Provider(IDP) que foi projetado para ser implementado sobre qualquer plataforma.
O IDP permite que aplicações se comuniquem e enviem comandos ao Interaction Manager. Este componente é usado para permitir que aplicações recebam informações úteis a certa da rede de dispositivos ou de um conjunto específico deles. Aplicações usarão o IDP como uma camada de abstrações que provêm interfaces diretas com os dispositivos remotos do lado da emissora.
Nossa solução não é uma parte mandatória ao middleware de TV digital que esteja executando do lado do telespectador. Ele é transmitido através do canal de broadcast como sendo uma aplicação interativa, dessa forma o IDP pode ser transmitido e executado com aplicações que dependam dele.
5.3.1
Interactive Device Provider (IDP) Architecture
Como o IDP precisa ser visto pelas aplicações como um canal de comunicação entre elas e a rede do lado da emissora, é preciso que ele trate muitos tipos de informações que são transmitidas através de o canal de broadcast e prover essa informação para as aplicações através de APIs de auto nível.
A arquitetura interna do IDP possuí duas camadas: A Camada de Baixo nível, que é diretamente conectada à plataforma de aplicações do sistema de TV sobre o qual o IDP foi implementado; E a Camada de Aplicação, que é responsável por se comunicar dire- tamente com a aplicação. A Camada de Baixo Nível tem quatro componentes principais que são mostrados na Figura 5.7:
• Data Handler: Este componente é responsável por tratar os dados transmitidos
através do canal de broadcast. Como o IDP é transmitido para o telespectador através dos mesmos mecanismos usados para transmitir qualquer aplicação, este módulo precisa ser mudado quando for necessário tratar diferentes tipos de métodos de transporte. Este componente funciona em paralelo ao sistema visando evitar métodos bloqueantes de forma a avisar aos demais componentes quando algum dado está pronto.
• Data Manager: Este componente interpreta os dados recebidos. Dessa forma o
Data Manager pode recuperar o stream de dados do Data Handler e decodificá-lo. Em nosso sistema os dados podem ser de duas formas. O primeito tipo é usado para representar os eventos gerados pelos Dispositivos de Interação quando uma mudança qualquer é feita na arquitetura lógica ou física da rede de dispositivos. O segundo tipo é relacionado com dados específicos do dispositivo. Quando dados de um dispositivo são recebidos por esse componente ele irá atualizar uma tabela interna com o estado de cada dispositivo, quando são recebidos eventos, ele apenas os repassará para o Event Manager.
• Communication Channel Manager: Este componente gerencia a comunicação
com o canal de retorno. Quando for necessário enviar informações do telespecta- dor para um dispositivo na emissora esse componente será encarregado de fazer a utilização das APIs de canal de retorno.
Cada camada é projetada para tratar dados específicos vindo da emissora ou de apli- cações que usam o IDP. Para ser integrado com nosso middleware uma implementação do IDP precisa ser projetada usando algumas interfaces e organizando cada sub-componente das camadas em partes de software.
A Figura 5.8 mostra uma especificação de classes mais detelhadas para os componen- tes da Camada de Baixo Nível. Esta especificação provê tanto métodos de comunicação quando os mecanismos para interagir com os dados transmitidos pela emissora. Os próxi- mos componentes vão usar estes como base para permitir aplicações interagirem com os dispositivos da emissora. É importante enfatizar que componentes contidos nessa camada podem mudar para suprir o que for necessário para prover novos tipos de eventos, tratar novos tipos de dados ou interagir com novos protocolos de canal de retorno.
A Camada de Aplicação depende dos componentes descritos previamente. Esta ca- mada provê as aplicações formas de tratar os Dispositivos de Interação através de seus três componentes principais listados abaixo:
• Device Manager: Foca em identificar que tipo de dispositivo é usado do lado da
emissora. Para cada dispositivo existirá um identificar único provido pela tabela de dispositivos no Data Manager. Este componente inspecionará a tabela por informa- ções sobre o dispositivo como ID do fabricante, tipo de dispositivo, etc. Os dados
5.3. COMUNICANDO O LADO DO TELESPECTADOR COM A ARQUITETURA37
Figura 5.8: Classes e Interfaces da Camada de Baixo Nível IDP.
enviados por cada dispositivo serão acessados pela aplicação através dos métodos desse componente.
• Life Cycle Manager: Este componente serve para instanciar e gerencia cada um
dos outros componente do IDP. Este componente será o ponto de acesso a todos os outros componentes do IDP, e irá ser responsável por instanciar cada subcompo- nente e integrá-los para que seus papéis sejam desempenhados corretamente.
• Event Manager: Quando eventos são detectados entre os dados recebidos do canal
de broadcast, esses são enviados a esse componente, que se encarregará de gerar um evento para as aplicações se atualizem sobre o estado da rede de dispositivos.
Figura 5.9: Classes e interfaces da Camada de Aplicação.
Na Figura 5.9 mostramos uma possível implementação da Camada de Aplicação. Aplicações que precisem usar os componentes do IDP precisam inicializá-lo através do componente Life Cycle Manager. Dessa forma todos os componentes estarão operacio- nais e futuros dados que venham pelo canal de broadcast serão tratados e notificados à aplicação.
Existem apenas três tipos de eventos que podem ser disparados quando algum dado específico é recebido:
• NewDeviceEvent: Disparado quando um evento que indica a entrada de um dispo-
sitivo na rede é recebido. Este evento tem três campos principais, o Device Id que contém o identificar do dispositivo, o Device Type que possui outro identificador para o tipo do dispositivo, e o ultimo Device Info que constitui um dado em for- mato de string que pode representar qualquer tipo de informação adicional sobre o dispositivo.
• RemoveDeviceEvent: Disparado quando um dispositivo deixa a rede. Este evento
tem apenas um campo contendo o ID do dispositivo que saiu da rede naquele mo- mento.
• DeviceDataEvent: Disparado quando dados contendo do dispositivo são enviados
pela emissora. Esse evento têm dois campos, o ID do dispositivo, e um campo Device Data que contem os dados no formato de string.
Nesta versão do IDP, aplicações precisam saber o tipo de protocolo que é usado para comunicação com os dispositivos, pois middleware suporta apenas o envio e recebimento de dados crus. De acordo com os valores providos pelo método getDeviceType, a aplica- ção pode identificar que tipo de protocolos usar.