Rafael Ferreira Rodrigues Ambiente Declarativo para Sistemas que ...

Rafael Ferreira RodriguesAmbiente Declarativo para Sistemas queImplementem o GEMDissertação de MestradoDissertação apresentada como requisito parcial paraobtenção do título de Mestre pelo Programa de Pós-Graduação em Informática da PUC-Rio.Orientador: Luiz Fernando Gomes SoaresRio de Janeiro, agosto de 2007

Rafael Ferreira RodriguesAmbiente Declarativo para Sistemas queImplementem o GEMDissertação apresentada como requisito parcial paraobtenção do título de Mestre pelo Programa de Pós-Graduação em Informática do Departamento deInformática do Centro Técnico e Científico da PUC-Rio.Aprovada pela Comissão Examinadora abaixo assinada.Prof. Luiz Fernando Gomes SoaresOrientadorDepartamento de Informática - PUC-RioProf. Renato CerqueiraDepartamento de Informática - PUC-RioProf. Rogério Ferreira RodriguesDepartamento de Informática - PUC-RioProf. José Eugenio LealCoordenador Setorial do CentroTécnico Científico – PUC-RioRio de Janeiro, 20 de agosto de 2007

Todos os direitos reservados. É proibida a reprodução totalou parcial do trabalho sem autorização da universidade, doautor e do orientador.Rafael Ferreira RodriguesGraduado em Engenharia de Computação pelo InstitutoMilitar de Engenharia (IME) em 2004. Atualmente, integrao grupo de pesquisadores do Laboratório TeleMídia daPUC-Rio, desenvolvendo pesquisas do GINGA-NCL.Rodrigues, Rafael FerreiraFicha CatalográficaAmbiente Declarativo para Sistemas queImplementem o GEM / Rafael Ferreira Rodrigues ;orientador: Luiz Fernando Gomes Soares. – Rio deJaneiro : PUC-Rio, Departamento de Informática, 2008.101 f. : il. ; 30 cmDissertação (mestrado) – Pontifícia UniversidadeCatólica do Rio de Janeiro, Departamento de Informática.Inclui referências bibliográficas1. Informática – Teses. 2. Gem. 3. NCL. 4. Java5. Ginga 6. TV Interativa. I. Soares, Luiz FernandoGomes. II. Pontifícia Universidade Católica do Rio deJaneiro. Departamento de Informática. III. Título.CDD: 004

Este trabalho é dedicado: a toda minha famíliae amigos, em especial meus pais, Jorgee Denize, minha irmã Robertae minha namorada Juliana.

AgradecimentosGostaria de agradecer primeiramente ao meu orientador Prof. Luiz Fernandopela confiança e pela forma de trabalhar tão inspiradora.A todos os integrantes do Laboratório TeleMídia que contribuíram direta ouindiretamente para a realização deste trabalho. Em especial agradeço ao Márcio,ao Carlão pela ajuda com as revisões. Preciso também agradecer ao Rogério cujapesquisa contribuiu diretamente para a elaboração desta dissertação.Aos meus amigos, e irmãos, Eduardo, Thiaguinho, Simão, Vinicius.Agradeço a toda a minha família pelo carinho e apoio incondicional. Emespecial a minha mãe Denize, minha irmã Roberta e a meu pai Jorge.Agradeço à minha namorada Jujuba por ter sempre sido compreensiva.Aos membros da banca pelos preciosos comentários e revisões.Agradeço a todos os professores e funcionários do Departamento deInformativa da PUC-Rio.Por fim, gostaria de agradecer ao CNPq, à CAPES, à FINEP e à PUC-Riopelo apoio financeiro fornecido ao longo deste mestrado.

ResumoRodrigues, Rafael Ferreira. Ambiente Declarativo para sistemas queimplementem o GEM. Rio de Janeiro, 2004. 101p. Dissertação deMestrado - Departamento de Informática, Pontifícia Universidade Católicado Rio de Janeiro.A existência de vários ambientes procedurais definidos para middlewares deSistemas de TV Digital terrestre levou à criação de um framework conhecidocomo Globally Executable MHP (GEM). Esse padrão visa a harmonização de taisambientes permitindo a execução global das aplicações. Nesse contexto, estetrabalho descreve a construção de um ambiente de apresentação declarativoutilizando a API fornecida pelo GEM de forma a permitir a execução global doconteúdo declarativo produzido para o Sistema Brasileiro de TV DigitalPalavras-chaveGEM, NCL, JAVA, Ginga, TV Digital Interativa

AbstractRodrigues, Rafael Ferreira. Declarative Environment for SystemsImplementing GEM Rio de Janeiro, 2004. 101p. Master Thesis -Departamento de Informática, Pontifícia Universidade Católica do Rio deJaneiro.The several procedural environment proposals for terrestrial Digital TVSystems led to the middleware framework recommendation known as GloballyExecutable MHP (GEM). This standard aims at the harmonization of suchenvironments allowing the global execution of procedural applications butneglecting the declarative ones. In this context, this work describes the integrationof the Ginga declarative environment using the API supplied by GEM andallowing the global execution of declarative contents produced for the BrazilianSystem of Digital TV (Sistema Brasileiro de TV Digital).Key wordsGEM, NCL, JAVA, Ginga, Interactive TV, Digital TV

Sumário1 Introdução .............................................................................................. 131.1. Motivação........................................................................................... 141.1.1. Ambiente Declarativo x Ambiente Procedural ................................ 171.2. Objetivos ........................................................................................... 181.3. Organização da Dissertação.............................................................. 192 Conceitos Preliminares .......................................................................... 212.1. Middlewares de TV Digital ................................................................. 212.1.1. O Middleware Europeu ................................................................... 232.1.1.1. Tipos de aplicações MHP ............................................................ 242.1.1.2. O uso de Plug-ins ........................................................................ 262.1.1.3. O uso do armazenamento de aplicações .................................... 282.1.2. O Middleware Americano................................................................ 292.1.3. O Middleware Japonês ................................................................... 312.1.4. O Middleware Brasileiro.................................................................. 322.2. Definição do padrão GEM.................................................................. 352.2.1. Políticas de segurança para execução de aplicativos no GEM.......362.2.2. Sinalização de Aplicações no GEM ................................................ 372.3. O Blue-Ray Disc ................................................................................ 392.4. Ambientes de Execução JAVA para TV ............................................ 402.4.1. O Modelo de programação XLET ................................................... 433 Trabalhos Relacionados ........................................................................ 473.1. O MHP Processando Documentos XHTML....................................... 483.2. Ambiente declarativo para TV Digital – UTH ..................................... 493.3. Ambiente declarativo para TV Digital – ICECREAM.......................... 504 O Fomatador NCL.................................................................................. 524.1. O Formatador NCL Java.................................................................... 524.2. O GEM processando um documento NCL ........................................ 554.3. A Arquitetura de Implantação ............................................................ 57

4.3.1. Estrutura do Sistema Baseada em Componentes.......................... 574.4. Adaptações e Otimizações no Formatador NCL ............................... 584.4.1. A Pré-conversão de Documentos NCL e o Módulo Gerenciadorde Documentos .................................................................................. 584.4.2. Adaptações do Módulo do Núcleo do Formatador ......................... 604.4.3. Adaptações do Módulo Gerenciador de Adaptadores paraExibidores e os Adaptadores Criados....................................................... 634.4.4. Adaptações do Módulo Gerenciador de Leiaute............................. 645 O Fomatador NCL Xlet ......................................................................... 665.1. Os Componentes do Formatador NCL Xlet ....................................... 665.1.1. Gerenciador de Leiaute .................................................................. 675.1.2. Gerenciador de Documentos .......................................................... 685.1.3. Núcleo do Formatador .................................................................... 695.1.4. Gerenciador de Adaptador para Exibidores.................................... 705.1.5. Adaptadores para Exibidores.......................................................... 705.2. Implementação dos Componentes para Sistemas GEM................... 715.2.1. O Carregamento Dinâmico ............................................................. 725.2.2. O Módulo de Implantação............................................................... 735.2.3. O Processo de Implantação do Formatador ................................... 765.2.4. Persistência do Formatador NCL Xlet em Receptores MHP .......... 785.3. Testes......... ....................................................................................... 796 Conclusões ........................................................................................... 836.1.Trabalhos Futuros............................................................................... 847 Referências Bibliográficas ..................................................................... 86Apêndice A Assinatura Digital de um Xlet ................................................ 91Apêndice B Sinalização de Aplicações..................................................... 94Apêndice C A Linguagem NCL ................................................................. 98

Lista de FigurasFigura 1 – O GEM e os demais padrões. .................................................16Figura 2 – Arquitetura de um sistema de TV Digital. ................................22Figura 3 - Perfis MHP. ..............................................................................24Figura 4 - Arquitetura básica do MHP.......................................................25Figura 5 – Opções de implementação de plug-ins. ..................................27Figura 6 – A interface Plugin.....................................................................28Figura 7 – Arquitetura do middleware Ginga. ...........................................34Figura 8 – O processo de identificação da AIT.........................................38Figura 9 – Arquiteturas de plataformas JAVA...........................................41Figura 10 – Exemplo de ambiente de execução Java..............................42Figura 11 – Protocolo entre as entidades presentes no modelo eprogramação Xlet......................................................................................44Figura 12 - Interface do Xlet. ....................................................................44Figura 13 - Máquina de estados do ciclo de vida de um Xlet. ..................45Figura 14 – Interface do XletContext. .......................................................45Figura 15 – Arquitetura da proposta do transcodificador..........................48Figura 16 – Arquitetura do Formatador NCL. ...........................................53Figura 17 – Pré-processamento do documento NCL. ..............................56Figura 18 – Processamento do documento NCL no receptor...................56Figura 19 – Modelo de uma apresentação NCL orientada a sincronizaçãopor contexto. .............................................................................................60Figura 20 – Digrama de classe da interface IFormatter............................62Figura 21 – Diagrama da interface NCLEditingCommandListener...........63Figura 22 – Diagrama de classes do modelo de leiaute do FormatadorNCL...........................................................................................................65Figura 23 – Duas implementações do componente Gerenciador deLeiaute ......................................................................................................67Figura 24 – Componente Gerenciador de Documentos. ..........................68Figura 25 – Duas implementações do componente do núcleo doformatador.................................................................................................69

Figura 26 – Duas implementações do componente do núcleo doFormatador ...............................................................................................69Figura 27 – Duas implementações do componente Gerenciador deExibidores .................................................................................................70Figura 28 – Duas implementações de adaptadores para exibidores........70Figura 29 – Classe GingaXlet. ..................................................................73Figura 30 – Classe IGingaXletConfiguration.............................................74Figura 31 – Interface IGingaXletDeployer.................................................74Figura 32 – A classe StreamEventHandler e suas associações. .............75Figura 33 – Diagrama de seqüência do processo de preparação doFormatador Xlet. .......................................................................................77Figura 34 – Diagrama de seqüência do processo de inicialização doFormatador Xlet. .......................................................................................78Figura 35 – Digrama de componentes do Sistema testado......................80Figura 36 – Arquitetura de execução distribuída do Formatador NCL. ....85Figura 37 – Exemplo de arquivo PRF.......................................................92Figura 38 – Estrutura de diretórios de um Xlet. ........................................93Figura 39 – Exemplo de documento NCL 2.0.........................................101

Lista de TabelasTabela 1 – Componentes do formatador GingaXlet .................................80Tabela 2 – Resultados dos testes de Serialização versus conversão......81Tabela 3 – Plataformas que implementam o CDC. ..................................84Tabela 4 – Exemplo resumido de uma tabela AIT....................................95Tabela 5 – Parâmetros adicionais da AIT para sinalização do FormatadorXlet............................................................................................................96

1IntroduçãoA possibilidade de se encapsular dados, juntamente com o áudio e vídeo,em sistemas de TV Digital, abre espaço para uma vasta gama de oportunidadescapaz de proporcionar uma maior interatividade para o telespectador. Essaintegração permite que a programação seja enriquecida através dadisponibilização de diversos serviços, como: guias eletrônicos de programação,votações, jogos, acesso a outras redes de comunicação, entre outros serviços. Essapossibilidade, contudo, exige um maior poder computacional da parte dosreceptores do sinal de TV digital para que, desta forma, tenham a capacidade deexecutar as aplicações para eles desenvolvidas.Devido à enorme diversidade de fornecedores de terminais de acesso, tornasenecessária, a fim de promover uma execução global das aplicaçõesdesenvolvidas pelos produtores de conteúdo, a criação de uma abstraçãodenominada middleware. O middleware fornece um conjunto comum deInterfaces de Programação de Aplicativos (Application Programming Interfaces –APIs) a serem oferecidas por todos os receptores que, entre outras facilidades,permitem o uso dos diversos recursos disponíveis nesses dispositivos.Dentre os sistemas de TV Digital terrestre em operação, os seguintespadrões de middleware figuram como principais:1. O europeu, denominado Multimedia Home Platform (MHP) (ETSI,2005b), definido pelo grupo do DVB (Digital Video BroadcastingProject);2. O americano, conhecido como DTV Application SoftwareEnvironment (DASE) (ATSC, 2003a), definido pelo grupo ATSC(Advanced Television Systems Committee); e3. O japonês, Integrated Services Digital Broadcasting (ISDB) (ARIB,2004), definido pelo grupo ARIB (Association of Radio Industriesand Businesses).

Introdução 14No âmbito brasileiro, encontra-se em desenvolvimento o middleware a serutilizado pelo sistema de TV digital deste país, batizado como Ginga, e parte doSistema Internacional para Difusão Digital Terrestre (Terrestrial InternationalSystem for Digital Broadcasting – ISDB-T), também conhecido como SBTVD.1.1.MotivaçãoO middleware europeu MHP, que contou com uma rápida popularização,adotou em seu ambiente procedural a linguagem JAVA (Gosling, 1996). Comisso, foi criado um nível maior de portabilidade para suas aplicações, permitindo oreuso de componentes de software provenientes de outras plataformas. Surgiram,então, algumas iniciativas para sua implementação sobre outras plataformasinternacionais. Entidades responsáveis pela padronização de sistemas de TVDigital, fora da Europa, manifestaram o interesse em ter parte do middlewareMHP implementado em suas especificações. Dessa forma, seria aproveitado todoseu desenvolvimento tecnológico e mantida uma compatibilidade que permitisseque as novas aplicações, como aquelas já desenvolvidas, pudessem serexecutadas/apresentadas em terminais de acesso desses outros padrões.Diante do interesse em se fazer uma integração entre os middlewaresprocedurais já existentes surgiu, então, o Globally Executable MHP (GEM)(ETSI, 2005a). O GEM, que pode ser considerado como um acordo deharmonização entre os principais padrões existentes, tem como base o MHP. Issoporque, além de capturar um subconjunto das interfaces, e toda a semânticadefinida por este padrão de middleware, o GEM também inclui as necessidadesimpostas por outros padrões internacionais.Com o GEM despontando como ambiente de execução procedural mínimopara os principais padrões de TV Digital (MHP, DASE e ARIB) e de mídiaempacotada (como o Blue-Ray Disc), tem-se aí uma base para a criação deaplicações e programas interativos portáveis para diversas plataformas.Middlewares procedurais compatíveis com a especificação do GEM vêm sendoadotados por vários países no mundo todo (MHP, 2006), inclusive pelo Brasil.Contudo, no GEM, como mencionado, é definido apenas um ambiente deexecução procedural, deixando livre para a implementação a definição de um

Introdução 15possível ambiente declarativo. Na Figura 1 são mostradas as especificações deambientes declarativos adotados pelos principais padrões que implementam oGEM. Nessa figura percebe-se, ainda, uma série de recomendações propostas peloórgão ITU (International Telecommunication Union).O ITU-T e ITU-R, em conjunto com outras organizações, como DVB,ARIB, ATSC, OpenCable e SMPTE, se organizaram para consolidar umatendência de harmonização que já vinha sendo demonstrada desde oestabelecimento do GEM. A recomendação ITU-T J.200 (ITU-T, 2001) foi criadavisando promover uma arquitetura de alto nível para um conjunto de formatos eAPIs mais harmônicos, capazes de prover várias funcionalidades necessárias paraaplicações interativas mais avançadas a serem oferecidas pelas redes de televisãopara os usuários domésticos. É o núcleo comum dos ambientes de aplicação paraserviços de TV Digital interativa. A recomendação estabelece tanto um ambientede execução declarativo (detalhado em ITU J.201) (ITU-T, 2004) quantoprocedural (detalhado em ITU-T J.202) (ITU-T, 2003). Contudo, esses ambientesnão precisam ser necessariamente independentes; podendo ser definidas pontesentre eles.A Figura 1 mostra a especificação ITU-T J.201 como compreendendo todoo ambiente declarativo das três principais implementações de middleware. Apesarda especificação prever um núcleo comum, mostrado no centro da áreapontilhada, é prevista sua extensão para certos requisitos específicos daimplementação.O núcleo é formado por:• Módulos definidos pelo padrão XHTML Modularization,especificado pelo W3C (World Wide Web Consortium) (W3C,2002);• O padrão CSS para descrever o estilo da apresentação, definido peloW3C (W3C, 1998);• A API DOM para alterar dinamicamente o conteúdo dosdocumentos XHTML, definida pelo W3C (W3C, 2004a); e• ECMAScript definido pela ECMA International (ECMA, 1999).Ainda na Figura 1, assim como no ambiente declarativo, a especificação doambiente procedural prevê um núcleo comum que é justamente o frameworkproposto pelo GEM. A especificação também permite a extensão desse núcleo

Introdução 16comum apresentando, em caráter informativo, os três padrões anteriormentemencionados.Figura 1 – O GEM e os demais padrões.Embora exista uma tendência clara à harmonização do middlewareprocedural, realizada pelo GEM, o mesmo não se pode dizer, de fato, com relaçãoao middleware declarativo. Apesar dos três padrões da Figura 1 adotarem umambiente baseado no padrão XHTML, com exceção do sistema japonês, essesambientes ainda não foram comercialmente implementados a contento.As limitações do modelo XHTML, a serem discutidas a seguir, e a falta daimplementação de um ambiente declarativo encorajam a criação de novosmecanismos que possibilitem a execução de aplicações/programas dessa natureza,através da criação de máquinas de apresentação (declarativas) baseadas na APIprocedural comum estabelecida pelo GEM.Na definição do subsistema declarativo do middleware brasileiro foipadronizada a utilização da linguagem NCL (Nested Context Language –Linguagem de Contextos Aninhados) (Soares & Rodrigues, 2006). Ao contráriodos padrões citados anteriormente, a NCL possui o foco no sincronismo de mídiase não é baseada no padrão XHTML. No entanto, essa linguagem mantém acompatibilidade com os demais padrões por permitir a definição de um exibidor

Introdução 17XHTML que viabiliza a utilização de conteúdo desta natureza como mídia a sersincronizada pelo documento NCL.Apesar de ser possível a reprodução do conteúdo declarativo dos demaispadrões pelo middleware brasileiro, o contrário não é possível. De forma aviabilizar tal compatibilidade, uma das alternativas é utilizar a API proceduralfornecida pelos padrões internacionais para a criação de um ambiente deapresentação declarativo para documentos NCL, que é o foco principal destadissertação.1.1.1.Ambiente Declarativo x Ambiente ProceduralEm um sistema de TV digital, um ambiente de execução procedural éaquele capaz de executar programas criados seguindo o paradigma deprogramação imperativo. Esses códigos apóiam-se, basicamente, na execuçãoalgorítmica de instruções fornecidas pelo programador. Dessa forma, oprogramador possui um maior controle da execução, sendo capaz de estabelecertodo o fluxo de controle e execução de seu programa. Contudo, é necessário que oprogramador seja mais qualificado e conheça bem os recursos da linguagem.Ambientes de apresentação declarativos, por sua vez, executam códigoscriados seguindo o paradigma de programação declarativo. No âmbito dos quatropadrões anteriormente mencionados, incluindo o brasileiro, suas linguagensdeclarativas são todas baseadas em XML (eXtensible Markup Language). Entreos exemplos de linguagens declarativas baseadas em XML (chamadas deaplicações XML) encontram-se a linguagem NCL (Nested Context Language –utilizada pelo SBTVD-T), a linguagem SMIL (Synchronized MultimediaIntegration Language – padrão W3C para sincronismo temporal de mídias)(W3C, 2005) e o XHTML, sendo esta a mais difundida atualmente.Ao contrário da linguagem procedural, que realiza a decomposição doproblema em implementações algorítmicas, a linguagem declarativa enfatiza adeclaração descritiva da solução do problema. A linguagem declarativa é maisindicada para aplicações cujo foco casa com o objetivo específico para o qual alinguagem foi desenvolvida. Na maioria dos casos, para TV Digital, as aplicações(não apenas aquelas carregadas pelo canal de difusão, mas também aquelas

Introdução 18carregadas pelo canal de retorno) lidam com a sincronização de objetos de mídia.A interação do usuário e a sincronização temporal com o áudio e vídeo principalsão exemplos de relacionamentos comuns entre objetos presentes nessasaplicações.1.2.ObjetivosEste trabalho tem como objetivo propor um ambiente de apresentação deprogramas declarativos desenvolvidos na linguagem NCL para sistemas queimplementem o GEM.No ambiente “virtual” implementado são utilizadas apenas as APIs JAVAfornecidas pelo framework GEM. Seu desenho foi concebido de forma a ser capazde operar sobre plataformas de recursos limitados.A solução proposta tem como base o Formatador NCL da implementação dereferência do middleware Ginga realizada pelo Laboratório TeleMídia da PUC-Rio. Contudo, foi necessária uma adaptação da implementação existente paradesktops, no intuito de permitir a compatibilidade com o GEM, sem perdercontudo a conformidade com o ambiente declarativo do Ginga.adaptados.Além do formatador, alguns de seus exibidores de mídia também foramComo uma das grandes dificuldades encontradas ao se executar aplicaçõesem ambientes de TV Digital é o seu tempo de iniciação, foram pesquisadosmecanismos para otimização do tempo de iniciação da execução do documento.Um destes mecanismos é o carregamento modular do formatador. Nodesenvolvimento realizado, apenas os módulos do formatador necessários para aapresentação em questão são obtidos do fluxo MPEG-2 Sistema. Além disso,quando o receptor permitir o armazenamento de aplicações ou plugins, épriorizado o carregamento do módulo pré-existente no receptor em detrimentodaquele transportado no fluxo MPEG-2 Sistema. Para realizar o processo deimplantação de tais módulos, foi criada uma estrutura independente. Essaestrutura possui a capacidade de abstrair dos demais módulos o acesso ao fluxo

Introdução 19MPEG-2 para o carregamento de bibliotecas e outros recursos necessários para aapresentação de um documento hipermídia.Outro mecanismo de otimização utilizado é a pré-conversão do documentoNCL. Esse mecanismo visa diminuir o número de etapas necessárias pelo receptorpara iniciar a execução de um documento, além de eliminar a necessidade de umabiblioteca para o processamento de documentos XML.1.3.Organização da DissertaçãoO restante desta dissertação encontra-se organizada como a seguir. NoCapítulo 2 são expostos conceitos acerca dos principais middlewares proceduraisexistentes sendo, a seguir, apresentado o GEM como harmonização de taismiddlewares. Após a apresentação do GEM é mostrado o primeiro padrão demídia empacotada a implementá-lo: o Blue-Ray Disc. É trazida, então, aoconhecimento do leitor a recomendação da máquina virtual Java mínima paraambientes procedurais de sistemas de TV Digital. A seguir, são apresentadas astecnologias envolvidas na construção de um ambiente declarativo para sistemasque implementem o GEM.O Capítulo 3 apresenta os trabalhos relacionados com o sistema proposto.Inicialmente são discutidas as alternativas para a implementação dos middlewaresdeclarativos baseados no XHTML como aplicações dos middlewares proceduraiscorrespondentes. A seguir, são discutidas duas aplicações para TV Interativa quefazem uso de uma máquina de apresentação de documentos SMIL no ambiente deexecução do middleware MHP. Ao final do capítulo, são apresentados osresultados de testes realizados por uma implementação SMIL em um sistema debroadcast de TV Digital.O Capítulo 4 apresenta a implementação Java do Formatador NCLdesenvolvida pelo laboratório de Telemídia da PUC-Rio e que serviu como basepara a elaboração deste trabalho, uma vez que o foco desta dissertação está naespecialização do Formatador NCL como uma aplicação GEM. A seguir, sãomostradas todas as adaptações necessárias à implementação Java do FormatadorNCL para a execução em um ambiente compatível com o GEM.

Introdução 20O Capítulo 5 apresenta uma proposta de um ambiente declarativo baseadona linguagem NCL para sistemas que implementem o GEM. Nesse capítulo édescrita a arquitetura e a implementação do sistema proposto. É mostrado comointegrar tal implementação a sistemas MHP utilizando as facilidades introduzidaspor sua interface de plug-ins e armazenamento de aplicações. Ao final docapítulo, são apresentados os resultados de alguns testes realizados.O Capítulo 6 apresenta uma análise dos resultados obtidos e sugestões parasuscitar trabalhos futuros.

2Conceitos PreliminaresNo capítulo anterior foram citados os três middleware para TV Digitalterrestre mais populares: o europeu (MHP), o americano (ATSC) e o japonês(ISDB). Além desses, foi citado um ambiente para a execução de aplicaçõesprocedurais em sistemas de mídia empacotada: o Blue-Ray Disc. Tais padrõesestabelecem uma série de requisitos mínimos a serem implementados por seusterminais. Neste capítulo são mostrados alguns desses requisitos relevantes para aconstrução de um ambiente de apresentação declarativo como uma aplicaçãoprocedural. É também feita uma breve descrição dos padrões mencionados, queconstituem as plataformas para as quais o sistema proposto é destinado.No intuito de descrever melhor as tecnologias envolvidas na construção dosistema proposto, este capítulo mostra, também, a configuração mínima de umamáquina virtual Java para uma plataforma de TV Digital.Para cumprir seus propósitos, este capítulo está organizado da forma aseguir. Na Seção 2.1, e em suas subseções, são apresentados os principaismiddleware procedurais para TV Digital aberta. A Seção 2.2 descreve o GEMcomo tentativa de harmonização desses padrões de middleware. A Seção 2.3mostra o padrão Blue-Ray: o primeiro padrão de mídia empacotada a implementaro GEM. E, por fim, na Seção 2.4 é apresentada a especificação mínima doambiente Java para sistemas de TV digital, inclusive o GEM.2.1.Middlewares de TV DigitalNuma arquitetura de serviços para TV Digital, o middleware consiste emuma abstração que atua entre duas camadas bem definidas. A razão de suaexistência está intimamente ligada à forma como ele interage com tais camadas.A camada inferior provê o serviço de transporte dos dados e o acesso àutilização dos recursos do terminal. Essa camada não é alvo de uma padronizaçãoformal, podendo ser especificada de acordo com os critérios do fabricante do

Conceitos Preliminares 22receptor. Ela engloba todo hardware e softwares nativos (drivers de dispositivos,sistema operacional, aplicações nativas).A camada superior é composta pelos aplicativos e serviços comuns aosusuários do sistema de TV Digital: guias eletrônicos de programação, jogos,cotação do mercado de ações, dentre outros serviços produzidos pelos provedoresde conteúdo/infra-estrutura.De forma a permitir que os aplicativos e serviços do sistema de TV Digitalsejam desenvolvidos independente da camada inferior, ou seja, do fabricante, foicriada uma camada intermediária: o middleware.Os middlewares são padrões que especificam requisitos mínimos a seremimplementados pelos fabricantes de forma a permitir uma execução global deaplicações e serviços para TV Digital. Tal padronização abrange, principalmente,APIs para acesso aos recursos da camada inferior, protocolos e formatos deconteúdo a serem suportados.Figura 2 – Arquitetura de um sistema de TV Digital.A Figura 2 ilustra o middleware exercendo seu papel de camadaintermediária entre o sistema operacional e os aplicativos e serviços comuns aosusuários do sistema de TV Digital.Os principais padrões de middleware para sistemas de TV Digital terrestreserão descritos nas seções a seguir.

Conceitos Preliminares 232.1.1.O Middleware EuropeuO middleware europeu MHP (Multimedia Home Platform) foi desenvolvidopor um consórcio de empresas denominado DVB (Digital Video Broadcast).Essas empresas são de áreas que incluem desde fornecedores de equipamentos atéas emissoras de TV. Ao elaborar novas resoluções, tal consórcio as encaminha aoETSI (European Telecommunications Standards Institute – um órgão responsávelpor padronizações na área de telecomunicações e ligado à União Européia) que,por fim, o estabelece como padrão. Seguindo esse processo, foram desenvolvidas,até então, duas versões do padrão MHP: o MHP 1.0 e o MHP 1.1.No MHP são estabelecidos dois níveis de categorização de suas aplicações:o primeiro enquadra a aplicação de acordo com os perfis dos usuários para osquais elas são dirigidas, definindo sua área de abrangência e, como conseqüênciarequisitos de processamento e comunicação dos terminais; e o segundo enquadraas aplicações de acordo com seu tipo (procedurais, declarativas ou híbridas).Os seguintes perfis de usuário/aplicação são definidos no padrão MHP 1.1na ordem do mais básico ao mais avançado, sendo que cada perfil é uma extensãodo perfil imediatamente mais básico:• Enhanced Broadcast Profile: É o perfil básico, projetado paraespelhar as funcionalidades fundamentais existentes em um sistemade middleware. Nesse perfil não existe interatividade direta com osprovedores de conteúdo, pois não há canal de retorno;• Interactive Broadcast Profile: A principal característica desse perfilé permitir que aplicações possam se comunicar por meio de umcanal de retorno. Esse perfil apresenta suporte para comunicação IPsobre o canal de retorno. Além disso, existe também grande suportepara interatividade com as APIs definidas;• Internet Access Profile: Esse perfil fornece grande poder deprocessamento e armazenamento, permitindo acesso a conteúdo daInternet no terminal de acesso. É previsto, obrigatoriamente, aexistência de um cliente de e-mail e um browser HTML sem, noentanto, tornar obrigatória a extensão promovida pela linguagemDVB-HTML (apresentada na próxima seção).

Conceitos Preliminares 24A Figura 3 apresenta os perfis citados ilustrando algumas das APIs etecnologias suportadas por cada versão do MHP.Figura 3 - Perfis MHP.2.1.1.1.Tipos de aplicações MHPAs aplicações MHP declarativas e procedurais são, respectivamente, oDVB-HTML e DVB-J (ou DVB JAVA). As aplicações DVB-HTML não sãomuito difundidas pelo fato de terem sido especificadas apenas na última versão dopadrão. Já as aplicações DVB-J possuem grande aceitação no mercado, pois asAPIs de suporte são obrigatórias em todos os perfis.Uma aplicação MHP, no entanto, não necessariamente precisa serexclusivamente procedural ou declarativa. Existem ainda, como mostrado naFigura 4, as aplicações híbridas. Nessas aplicações é prevista a existência deelementos em ambas as linguagens, denso prevista uma ponte que permite a

Conceitos Preliminares 25comunicação entre as aplicações que pertençam a esses dois paradigmasdiferentes.Figura 4 - Arquitetura básica do MHPAplicações DVB-HTML são baseadas em alguns padrões estabelecidos peloW3C. Essas aplicações são descritas em uma linguagem que estabelece umaextensão ao XHTML adotando, em conjunto com este, os padrões, Cascade StyleSheets (CSS - responsável pela formatação e layout de páginas HTML),ECMAScripts (responsável por habilitar interatividade em documentos XHTML)e Document Object Model (fornece abstração que permite, através doECMAScript, manipular estruturas e conteúdos de documentos XHTML).Já as aplicações DVB-J constituem programas em código binário JAVA.Esses programas, no entanto, diferente das versões de aplicação JAVA destinadaa desktops, devendo obedecer a uma série de APIs mais restritivas definidas peloMHP (ETSI, 2005). São elas:• JavaTV: Introduz uma série de funcionalidades específicas para oambiente de TV interativa, como localização de conteúdo, controle dociclo de vida da aplicação, controle de acesso, sintonização einformação sobre serviços. Os programas que utilizam essa API sãotambém denominados Xlets.• JMF: O Java Media Framework é uma API que gerencia ocomportamento e a interação de objetos de mídia contínua. JMF é

Conceitos Preliminares 26utilizado para capturar, processar e apresentar alguns tipos de mídiascontínuas.• HAVi User-Interface: é uma API que permite ao programador criarelementos para a interface com o usuário. Provê uma extensão ao pacote“java.awt”, permitindo, assim, suporte a controle remoto, transparência,entre outros;• DAVIC: Apresenta alguns requisitos de sistemas audiovisuais paraprover interoperabilidade fim-a-fim;• DVB-MHP: Essa API utiliza os serviços providos pelas classes dasAPIs já mencionadas (ou seja, na prática provendo a mesmafuncionalidade) e adiciona serviços novos, como gerenciamento daconexão do canal de retorno, armazenamento de informações,manipulação de eventos, segurança, gerenciamento de aplicações ecarregamento de plug-ins.O MHP fornece dois mecanismos auxiliares que permitem a instalação deaplicações de forma persistente nos receptores dos usuários. São eles: o uso dosplug-ins e o Application Storage (armazenamento de aplicações). Nas subseçõesseguintes serão apresentados esses dois mecanismos.2.1.1.2.O uso de Plug-insPlug-ins são conjuntos de funcionalidades que podem ser adicionadas a umaplataforma genérica de forma a prover a interpretação de formatos de aplicaçãoregistrados junto ao DVB. Atualmente, encontram-se registrados dois formatos deaplicações: o HTML 3.2, que também indica aplicações no formato XHTML esuas derivadas como o DVB-HTML, e o MHEG-5 (ISO, 1997). A Figura 5mostra os dois tipos possíveis de plug-ins: nativos (na figura como plug-in B) einteroperáveis (na figura como plug-in A).Os plug-ins nativos usam código específico da implementação do receptor,ou seja, código nativo. Esse tipo de código pode, inclusive, ser especificado nalinguagem Java, desde que não sejam utilizadas as APIs do MHP, caso contrario,

Conceitos Preliminares 27deixam de ser considerados nativos. O processo de sinalização das aplicações 1 ,tanto do plug-in como das aplicações por ele processadas, também deverá sernativo.Figura 5 – Opções de implementação de plug-ins.Já um plug-in interoperável é aquele que necessita apenas das APIsespecificadas pelo padrão MHP, permitindo dois tipos de sinalização: umafornecida pelo padrão e outra específica da implementação.A sinalização padrão do MHP para plug-ins, prevê a existência de doistipos de descritores a serem utilizados pela tabela AIT: um descritor de aplicaçãopara o plug-in e outro para a aplicação por ele processada. Esses descritores sãomostrados em mais detalhes no Apêndice B. A sinalização prevê, ainda, que oponto de entrada do plug-in seja uma classe que implemente a interfaceorg.dvb.application.plugins.Plugin mostrada na Figura 6. Com isso, asaplicações processadas por ele serão reconhecidas como Xlets e controladas peloGerenciador de Aplicações.Na sinalização específica da implementação, a aplicação processada peloplug-in não será reconhecida como uma aplicação MHP (Xlet). Com isso todo seucontrole (ciclo de vida, etc.) deverá ser realizado pelo próprio plug-in.1 A sinalização de aplicações define formas de se identificar e iniciar aplicações associadasa um serviço. Ela deve também oferecer mecanismos pelos quais as difusoras possam gerenciar ociclo de vida de suas aplicações.

Conceitos Preliminares 28public interface Plugin{plubic Xlet initApplication(AppAttributes app)throws InvalidApplicationException;public Xlet initApplication(InnerApplication app)throws InvalidApplicationException;public boolean initPlugin();public isSupported(AppAttributes app);plubic void terminatePlugin();}Figura 6 – A interface Plugin.A interface org.dvb.application.plugins.Plugin, mostrada na Figura6, visa, como mencionado, permitir ao Gerenciador de Aplicações manter ocontrole do ciclo de vida das aplicações sendo executadas pelo plug-ininteroperável. Para isso, essa interface reusa o modelo de programação Xlet deforma a representar aplicações em formatos diferentes do DVB-J.A classe que implementar essa interface não poderá realizar nenhumaoperação que consuma muito processamento em seu construtor. Todas as rotinasde iniciação serão realizadas em seu método initPlugin. Esse método seráchamado sempre antes do método utilizado pelo Gerenciador de Aplicações parainiciar a aplicação (initApplication). No método initApplication serão passados,ainda, os parâmetros do descritor da aplicação, presente na tabela AIT, para que aaplicação possa ser tratada pelo plug-in. O método terminatePlugin será chamadoao término da execução da aplicação.A grande vantagem introduzida por essa facilidade é o fato de umaaplicação de conteúdo genérico ser sinalizada para os receptores e interpretadapor eles como uma aplicação MHP (Xlet). Isso contribui para a adoção do padrãoDVB-HTML para aplicações declarativas, permitindo sua introdução como pluginMHP nos perfis Enhanced Broadcast e Interactive Broadcast (Perrot, 2001).2.1.1.3.O uso do armazenamento de aplicaçõesA especificação do MHP prevê uma API opcional denominadaApplication Storage. Os receptores que implementam tal API são capazes deinterpretar um tipo de sinalização de aplicação que permite o armazenamento deprogramas. Esse mecanismo provê uma série de vantagens:• Permite a aplicação armazenada seja iniciada a qualquer momentopelo usuário ou pela difusora;• Permite o controle de versão da aplicação;

Conceitos Preliminares 29• Permite a instalação automática de aplicações sem a necessidadede elaborar outras aplicações com tal finalidade (ou seja,aplicações que armazenam aplicações);• Permite a desinstalação de aplicações.Utilizando a API padrão de persistência da especificação MHP seriapossível, também, armazenar aplicações. Contudo, tornaria necessário o envioprévio de outra aplicação para executar o carregamento das aplicações originaisdo disco.Mais informações sobre o mecanismo de sinalização do MHP podem serencontradas no Apêndice B.2.1.2.O Middleware AmericanoO Advanced Television Systems Committee (ATSC) é uma organizaçãoamericana responsável por estabelecer padrões para TV. Esse comitê foi formadoinicialmente pela Electronic Industries Association (EIA), Institute of Electricaland Electronic Engeneers (IEEE), National Association of Broadcasters (NAB),National Cable Television Association (NCTA) e Society of Montion Picture andTelevision Engineers (SMPTE).Inicialmente, foi desenvolvido pelo ATSC um padrão denominado DTVApplication Software Environment Level 1 (DASE-1). O DASE adota modelos deaplicações baseados em linguagem procedural e declarativa. No ambientedeclarativo é adotado o XHTML e no procedural a linguagem JAVA.Em sua primeira versão o DASE era restrito apenas à interatividade local,pois o sistema não previa um canal de retorno. Contudo, surgiram ainda o DASEnível 2 e o DASE nível 3. No primeiro foram resolvidas questões relativas àsegurança, como a criptografia dos dados; e, no segundo, já prevendo o canal deretorno, foi estabelecida uma integração da TV com a internet, dando acesso aprogramas de correio eletrônico, navegadores web entre outros, no terminal deacesso.Paralelamente a essa iniciativa, desenvolveu-se o OpenCable ApplicationsPlataform (OCAP) (OCAP, 2005). Esse padrão foi estabelecido pela CableLabs:um consórcio formado por membros da indústria de TV a cabo. Ele conta apenas

Conceitos Preliminares 30com o ambiente procedural para execução de aplicações denominadas OCAP-J edesenvolvidas para plataforma JAVA.Dado o cenário mencionado, com dois tipos de middleware despontando noterritório americano e a clara tendência à harmonização proposta pelo GEM, oATSC introduziu a especificação do Advanced Common Application Plataform(ACAP).Middleware Americano ATSC/ACAPO padrão ACAP surgiu a partir de um trabalho em conjunto comparticipantes do DVB em setembro de 2004. Sua especificação é primariamentebaseada no GEM e no DASE e inclui funcionalidades adicionais do OCAP. Elafoi criada com o intuito de substituir o DASE e permitir uma compatibilidade como GEM e com o OCAP. Dessa forma, além de permitir a criação de aplicaçõesportáveis dentre os middlewares americanos e os compatíveis com o GEM, opadrão permite uma compatibilidade com as aplicações já existentes em territórioamericano.As aplicações ACAP são classificadas em duas categorias: conteúdosprocedurais ou conteúdos declarativos. As aplicações contendo apenas conteúdoprocedural são denominadas ACAP-J e as contendo conteúdo declarativo ACAP-X. Similar ao MHP, o ACAP classifica as plataformas que o implementam emdois perfis: o perfil ACAP-J, no qual a plataforma é obrigada a implementarapenas o suporte às aplicações procedurais; e o perfil ACAP-J e ACAP-X, queobriga a plataforma a dar suporte a programas procedurais, declarativos ehíbridos. Esse enquadramento torna a existência de um ambiente declarativofacultativo e reforça a idéia de compatibilidade com o GEM.No ambiente ACAP-X, as aplicações são representadas por documentoshipermídia compostos por meio de uma linguagem de marcação (e.g. XHTML),regras de estilo (CSS), scripts (ECMAScritpt), Xlets embutidos (aplicaçõesACAP-J), e elementos audiovisuais. Toda a definição desse ambiente é baseadaem extensões/restrições da definição do DVB-HTML.O ambiente ACAP-J é uma combinação do GEM, OCAP e DASE. Por isso,todo conteúdo obrigatório estabelecido no ambiente procedural desses padrões

Conceitos Preliminares 31são incluídos no ambiente ACAP-J. São previstas ainda, as seguintes extensões àAPI JAVA:• API para Closed Captioning;• API para localizadores de conteúdo específicos para o ACAP;• API para o tratamento de eventos na interface com usuário;• API para identificação do conteúdo;• API estendendo a SI (Service Information)• Integração DOM entre ambientes, que visa realizar a ponte doambiente procedural com o declarativo quando este existir;Contudo, apesar da interoperabilidade provida pelo padrão soar promissora,a especificação do padrão é relativamente recente. Isso contribui para haver aindaquase nenhuma penetração sua dentre os consumidores americanos.Middleware Americano CableLabs/OCAPA especificação OCAP 1.0 foi estabelecida em 2001. No entanto, apesar doestabelecimento da proposta de middleware ACAP pelo ATSC, a evolução doOCAP continuou a ocorrer paralelamente. Depois de algumas revisões, o padrãopassou a implementar diretamente a API do GEM: o OCAP 1.0 I-16 (revisão 16),estabelecido em 2005, baseia-se no DVB-GEM 1.0.2 e DVB-MHP 1.0.3. Depoisdisso, acompanhando a evolução do GEM, em 2006 foi lançado o OCAP 1.1correspondendo ao DVB-GEM 1.1 e DVB-MHP 1.1.2.2.1.3.O Middleware JaponêsA especificação do sistema para transmissão digital terrestre japonês foiproduzida em 1997 pela associação de indústrias e negócios de rádio japonesa(ARIB – Association of Radio Industries and Business), tendo contado com umaaprovação final pelo governo Japonês. Tal especificação estabeleceu o padrãoconhecido como Terrestrial Integrated Services Digital Broadcasting (ISDB-T).

Conceitos Preliminares 32Assim como na maioria dos demais sistemas, a arquitetura ARIB écomposta por dois subsistemas: um para a execução de programas procedurais; eoutro para a apresentação de programas declarativos. Entretanto, no padrãojaponês não foram definidos elementos capazes de estabelecer uma ponte entreesses dois subsistemas.A linguagem utilizada no ambiente declarativo é denominada BML(Broadcast Markup Language). Essa linguagem encontra-se definida naespecificação ARIB STD-B24 Volume 2 (Data Coding and TransmissionSpecification for Digital Broadcasting Vol. II). Ela baseia-se no XHTML efornece suporte a CSS e ECMAScript.No BML, o ECMAScript foi estendido de forma a fornecer uma API capazde oferecer, principalmente, as seguintes funcionalidades:• Controle do canal de retorno;• Controle da apresentação;• Alteração do conteúdo da página em tempo real;• Processamento de eventos gerados pela emissora; e• Processamento de eventos oriundos da interação com o usuário.O ambiente de execução procedural foi definido na especificação ARIBSTD-B23 (Application Execution Engine Platform for Digital Broadcasting) em2003. Atualmente o padrão se encontra em sua revisão 1.1 estabelecida em 2004.O ambiente consiste de um sistema capaz de executar programas em bytecodeJAVA e foi criado a partir de uma extensão do GEM 1.0 e do DVB MHP 1.0.Entretanto, ao contrário dos outros padrões, existe no mercado japonês uma maiorpenetração de aplicações declarativas e receptores que implementem suporte a talparadigma. Isso se deve, possivelmente, ao fato da padronização tardia doambiente procedural.2.1.4.O Middleware BrasileiroA proposta para o middleware utilizado pelo ISDTV-T, cuja arquitetura émostrada na Figura 7, compreende a implementação de dois subsistemas:

Conceitos Preliminares 33• Um provê uma infra-estrutura para a execução de aplicaçõesbaseadas na linguagem procedural Java, sendo denominado Ginga-J(ilustrado na figura à direita da ponte); e• O outro provê uma infra-estrutura para a apresentação de aplicaçõesbaseadas em documentos hipermídia escritos na linguagemdeclarativa NCL, sendo denominado Ginga-NCL (ilustrado nafigura à esquerda da ponte).No entanto, as aplicações não necessitam ser exclusivamente procedurais oudeclarativas. Existem elementos em ambos os subsistemas que permitem aconstrução de aplicações híbridas: uma aplicação declarativa (NCL) pode possuiroutra aplicação procedural embutida; ou, por outro lado, uma aplicaçãoprocedural pode referenciar o conteúdo declarativo, como, por exemplo, criando einiciando apresentações.O uso da linguagem NCL em ambientes de TV Digital interativa visagarantir o sincronismo quando da reprodução de programas interativosmultimídia, hipermídia e não-lineares. A entidade responsável pela apresentaçãode documentos NCL é denominada Formatador NCL.A partir da especificação do documento NCL recebida, o Formatadorconstrói um plano de apresentação que contém as características de apresentaçãode cada objeto de mídia, a programação das tarefas a serem escalonadas e asinformações dos relacionamentos de sincronização entre os objetos de mídia.Baseado nos eventos gerados pelos exibidores de mídia e nos eventos geradospelo usuário, o escalonador de apresentação controla a execução sincronizada detodo o documento, realizando ajustes quando esses se fazem necessários(Rodrigues, 2003).Na Figura 7 são mostrados, ainda, dois exibidores que devem serimplementados pelo middleware: o exibidor XHTML, que deve possuir uminterpretador ECMAScript e suporte a CSS; e o exibidor Lua (Ierusalimschy,2003), que representa uma máquina virtual dessa linguagem.Dependendo da implementação fornecida pelo módulo XHTML omiddleware pode se tornar compatível com outros padrões declarativos (BML,ACAP-X, DVB-HTML). Mais ainda, ao padronizar a existência de tal módulo,torna-se o middleware compatível com o padrão ITU-T J.201.

Conceitos Preliminares 34Para que outros tipos de conteúdo, além dos citados anteriormente, possamser apresentados no ambiente declarativo, é necessária a criação de adaptadoresque respeitem a API de Adaptadores do Formatador. Essa API permite que osexibidores desses outros tipos de conteúdo sejam controlados de acordo com omodelo de apresentação do Formatador NCL.Outra estrutura importante na arquitetura é o Gerenciador de Bases Privadas.Esse gerenciador é responsável por lidar com um conjunto de bases responsáveispor armazenar documentos NCL. Tais estruturas são denominadas privadasdevido ao fato de cada base ser de uso exclusivo de um canal de TV específico.As atividades do Gerenciador de Bases Privadas incluem, além de asseguraro acesso exclusivo a essas bases, o processamento de Comandos de Edição NCL(Soares et al, 2006). Esses comandos permitem, por exemplo, a alteração de umdocumento NCL durante sua apresentação.Figura 7 – Arquitetura do middleware Ginga.O subsistema procedural (Ginga-J) constitui uma extensão à especificaçãodo GEM, mantendo, dessa forma, a compatibilidade com todos os demais padrõesque implementam tal especificação (DVB MHP, ATSC ACAP e OCAP, ISDBARIB). A API proposta pelo Ginga-J pode ser dividida em três porções: a porçãodefinida pelo GEM; a porção definida pelo Ginga-J mas adaptável ao GEM; e aporção definida apenas pelo Ginga-J.

Conceitos Preliminares 35Dentre as inovações introduzidas pelo subsistema procedural do middlewarebrasileiro, pode-se destacar o suporte a interações multiusuário, multidispositivo emulti-rede de comunicação, com o receptor (Filho et al., 2007).Abaixo desses dois subsistemas lógicos (Ginga-NCL e Ginga-J) existe umacamada, que lhes oferece suporte, denominada Núcleo Comum. Essa camada écomposta por decodificadores comuns de conteúdo (como PNG, JPG, GIF ouMPEG) e rotinas para obter conteúdos transportados no Fluxo de TransporteMPEG-2 (ISO, 1993) e via canal de retorno. Possui ainda uma Máquina VirtualJava (JVM – Java Virtual Machine) para a execução de códigos binários dessalinguagem.2.2.Definição do padrão GEMO GEM (Globally Executable MHP) foi proposto, inicialmente, para que asaplicações MHP pudessem ser utilizadas sobre as plataformas do middleware dosEUA (CableLabs) e do Japão (ARIB). O GEM é considerado um acordo deharmonização. Isso porque, além de capturar as interfaces e toda a semânticadefinidas pelo MHP (independentes da plataforma DVB), o GEM inclui asnecessidades impostas por outros padrões internacionais. A CableLabs participouda composição da primeira versão do GEM, para tornar compatível seumiddleware para a TV a cabo americana, o OCAP. E, mais recentemente, omiddleware japonês ARIB e o candidato a padrão americano ACAP tambémtiveram suas necessidades de harmonização com o GEM concluídas e podem,dessa forma, ser classificados como padrões compatíveis com o GEM.Formalmente, o GEM por si só não pode ser considerado uma especificaçãocompleta para terminais de acesso. O correto é dizer que GEM é um framework apartir do qual um terminal de acesso pode ser implementado, ou ainda, que GEMé um padrão ao qual implementações existentes devem se adaptar para obter umaconformidade que garante a execução global de aplicações. O padrão define,portanto, um conjunto de APIs, garantias semânticas, protocolos e formatos deconteúdo com os quais as aplicações (agora globalmente interoperáveis) podemcontar para a constituição de serviços interativos, executáveis em qualquerplataforma definida pelos padrões internacionais compatíveis.

Conceitos Preliminares 36Por definir um framework baseado no padrão MHP, o documento deespecificação do GEM é na realidade uma listagem de referências a outrosdocumentos do consórcio DVB. Ele descreve as diversas partes do MHP que sãoindependentes do padrão DVB e salienta aquelas que devem ser substituídas deacordo com a infra-estrutura de implementação das novas especificaçõescompatíveis. Esses pontos de flexibilização do GEM devem ser, então,preenchidos por “equivalentes funcionais” – mecanismos que lançam mão deoutras tecnologias (definidas pelas respectivas organizações de TV digital) paraimplementar uma funcionalidade análoga àquela proposta pelo DVB. Taistecnologias passam a ser qualificadas como equivalentes funcionais somente apósnegociações entre o consórcio DVB e cada uma das organizações que requisitama conformidade com o GEM.No GEM, diferente do DVB, são definidos apenas os dois primeiros perfis:o Enhanced Broadcast e o Interactive Broadcast.2.2.1.Políticas de segurança para execução de aplicativos no GEMTodo Xlet a ser executado em ambientes que implementem o GEM estásujeito a uma série de restrições de segurança. Nem todos os recursos do receptor,disponíveis no ambiente Java, têm seu uso diretamente permitido a umaaplicação. De acordo com o padrão, as aplicações que são enviadas para umreceptor serão classificadas como não confiáveis e não possuirão acesso a toda aAPI Java.Para garantir um nível maior de confiabilidade à aplicação, é necessária suaassinatura digital. Uma aplicação assinada pode ter suas permissões de acessoalteradas através de um Arquivo de Requisição de Permissão (Permission RequestFile – PRF).Os PRFs são arquivos XML que devem estar presentes no mesmo diretóriodo arquivo inicial de uma aplicação que necessite de alterações em seu nível deacesso padrão. Nesses arquivos, o identificador formal da DTD deve corresponderà organização que especificou o documento. Além disso, o prefixo do PRF deveidentificar a especificação de terminal GEM (Ex.:

Conceitos Preliminares 37ocap..perm). Um exemplo de tal arquivo pode serencontrado no Apêndice A.Os objetivos das alterações realizadas pelos PRFs são as permissões JAVA.As permissões Java representam o acesso a um recurso do sistema (SUN, 2002).A permissão tem um nome (normalmente o nome do alvo) e, comumente, umalista de um ou mais parâmetros (ex.: java.io.FilePermission “/tmp/abc/”, “read” –permite a leitura dos arquivos no diretório “/tmp/abc/”). As permissões maisrelevantes disponíveis para utilização em um PRF e necessárias para aimplementação de um ambiente declarativo virtual são:• org.dvb.net.tuning.TunerPermission: permissão para realizar atroca entre os fluxos;• org.dvb.user.UserPreferencePermission: permissão paraleitura/escrita das preferências do usuário. Sendo a leitura permitidatambém para aplicativos não-assinados;• java.net.SocketPermission: permissão para se comunicar com hostsremotos (como por exemplo abrir uma página HTML externa); e• java.io.FilePermission: permissão de leitura/escrita dos arquivos.Sendo a leitura permitida também para aplicativos não-assinados;• org.dvb.application.AppsControlPermission: permissão paracontrolar o ciclo de vida da aplicação;• org.dvb.net.rc.RCPermission: permissão para comunicaçãoutilizando o canal de retorno (connect, listen, resolve).2.2.2.Sinalização de Aplicações no GEMNa especificação do GEM são fornecidos requisitos mínimos desinalização que devem ser implementados pelos padrões baseados nessaespecificação:• para qualquer aplicação: seu descritor deve possibilitar aidentificação do nome da aplicação; o identificador único da

Conceitos Preliminares 38aplicação e da organização que a produziu; e a localização daaplicação e demais arquivos por ela utilizados; e• para aplicações procedurais (e.g. Java): deve ser fornecidainformação suficiente para sinalizar os parâmetros da aplicação eindicar sua classe inicial.Uma forma de implementar tais mecanismos é utilizando a Tabela deInformação de Aplicações (Application Information Table – AIT). Toda ainformação sobre as aplicações que podem ser obtidas via carrossel de objetos ouvia canal de retorno são armazenadas nessa tabela. Ela é enviada em conjuntocom outros fluxos elementares em um fluxo de transporte MPEG-2.Na Figura 8 é mostrado o processo de identificação da AIT em um fluxode transporte MPEG-2. A Tabela de Associação de Programas (ProgramAssociation Table – PAT) pode ser encontrada nos pacotes de fluxo de transporteidentificados pelo PID 0. Supondo que a AIT da aplicação está associada com oprograma 2, a Tabela de Mapeamento de Programa (Program Map Table – PMT)pode ser identificada nos pacotes com o PID 23. Na PMT, se o tipo de fluxopossuir o valor 0x05, que representa o fluxo do tipo AIT, então os pacotes com oPID 0x200 estarão carregando a AIT correspondente a esse programa.Figura 8 – O processo de identificação da AIT.

Conceitos Preliminares 39No Apêndice B é ilustrada como é formada a AIT em um sistema de TVDigital que utilize o DVB-MHP.2.3.O Blue-Ray DiscO disco Blue-Ray (BD – Blue-Ray Disc) é uma revolução em termos dearmazenamento em mídia ótica para consumidores de produtos eletrônicos, PCs econsoles de vídeo game (Playstation 3). Ele proporciona: uma resolução de altadefinição de 1920 x1080, comparada aos 720x480 proporcionados pelo DVD e os352x240 pela TV analógica; e uma capacidade de armazenamento de 25GB e 50GB, atualmente, e até 200GB, com o lançamento futuro de discos multicamadas.Com relação à interatividade, para uma plataforma BD encontram-sedefinidos dois modos de operação que podem, inclusive, coexistir:• High Definition Movie (HDMV) – esse modo enfatiza umacompatibilidade com os processos de produção dos DVDs atuais. Omodo HDMV suporta todas as funcionalidades proporcionadas pelosDVDs atuais e seus formatos. Contudo, proporciona melhoras naqualidade do vídeo, áudio, definição, experiência do usuário, entreoutros; e• BD-J – um ambiente de aplicações programáveis com possibilidadesde canal de retorno, possibilitando aos produtores de conteúdo umaalta interatividade e títulos BD-ROM atualizáveis.Foi estabelecida pela BDA (Blue-ray Disc Association) a linguagem JAVAcomo tecnologia a ser adotada em aplicações BD-J. Isto possibilita a criação deaplicações com interatividade avançada proporcionando-se as seguintes vantagensao BD em relação ao DVD: liberdade para o desenho da interface com o usuário;controle da execução do áudio e vídeo; atualização dinâmica do conteúdo(trailers, legendas, materiais de bônus) via um canal de retorno; outras formas deconteúdo (jogos interativos no disco e online, eventos ao vivo, compras online).Ao adotar como linguagem o JAVA, a BDA, buscando seguir a tendênciaglobal de harmonização dos ambientes de execução procedural para sistemas deTV digital, estabeleceu que as plataformas BD deveriam implementar oframework GEM.

Conceitos Preliminares 40Seguindo a especificação do GEM, o padrão BD-J também define doisperfis para suas aplicações:• BD-VIDEO – esse perfil não requer canal de retorno; e• BD-LIVE – esse perfil requer canal de retorno proporcionando odownload de conteúdos e aplicações novas.2.4.Ambientes de Execução JAVA para TVUm ambiente de execução Java (Java Runtime Environment – JRE) é umaimplementação da tecnologia Java para uma plataforma específica. Ele é instaladoe executado como uma aplicação nativa com o propósito de executar e gerenciaraplicativos JAVA. O JRE fornece, portanto, uma abstração comum para asaplicações JAVA e é implementado em código nativo.A tecnologia Java pode ser subdividida como mostra a Figura 9. Estadivisão procura enquadrar essa tecnologia em algumas plataformas-alvo:• A edição Java EE (antiga J2EE) é voltada para o segmento dosservidores, é uma edição que possui recursos avançados paraaplicações empresariais;• A edição Java SE (antiga J2SE) é a edição padrão recomendada paraa maioria das plataformas, incluindo, principalmente, desktops; e• A edição Java ME (antiga J2ME) é a edição para plataformas comrecursos limitados como PDAs, celulares, set-top boxes, quiosques,terminais de impressão, entre outros.A Java ME é, dentre todas as edições citadas, a que precisa se adequar àmaior variedade de dispositivos. Além disso, para ganhar relevância ela deve seramplamente adaptável, pois a categoria de produtos por ela compreendida está emconstante evolução: os fornecedores estão constantemente adicionando novasfuncionalidades e identificando novos nichos de produtos (SUN, 2005a). Paraisso, a edição Java ME prevê algumas alternativas de configurações, perfis epacotes opcionais para um ambiente de execução Java específico para umproduto.

Conceitos Preliminares 41Figura 9 – Arquiteturas de plataformas JAVA.O CLDC (Connected Limited Device Configuration) é uma configuraçãovoltada para telefones celulares e PDAs de pequeno porte. Essa configuraçãodefine um pequeno subconjunto da API fornecida pelo Java SE e compartilhadacom o CDC. O objetivo principal do CLDC é a economia da memória. Para isso oambiente de execução não oferece funcionalidades como API de reflexão e ocarregamento de classes pela aplicação. Com essa economia os dispositivos queimplementam tal configuração possuem uma necessidade de memória de apenas128 KB a 256 KB.O CDC (Connected Device Configuration) tem como objetivo principal acompatibilidade com o Java SE e suportar dispositivos com recursos limitados.Ele suporta a implementação completa da máquina virtual Java incluindocarregamento de classes e suas classes essenciais. Contudo, para atender aorequisito de operar sobre plataforma de recursos limitados, o CDC realizamodificações no Java SE: algumas de suas classes tiveram suas interfacesmodificadas e outras retiradas inteiramente. Dessa forma, o requisito dessaconfiguração fica na casa dos 2 MB de RAM e 2MB de ROM.Existem definidos para o CDC três perfis. A definição desses perfisproporciona aos fabricantes uma maior flexibilidade, trazendo diferentes níveis de

Conceitos Preliminares 42sofisticação à implementação e possibilitando o suporte a diferentes tipos dedispositivos com um ambiente de execução Java compatível. São eles:• Foundation Profile (FP) – é o perfil mais básico. Possui apenasbibliotecas básicas como rede e Entrada/Saída (I/O). Esse perfil nãosuporta a criação de gráficos nem interfaces gráficas com o usuário(GUIs);• Personal Basis Profile (PBP) – É o perfil intermediário e incorpora oFP. Permite a construção de GUIs através de um subconjuntolimitado do AWT (Geary & McClellan, 1997) e também implementao modelo de programação Xlet que será visto a seguir; e• Personal Profile (PP) – É o perfil CDC mais avançado e engloba oPBP além de suportar integralmente o AWT e applets (SUN, 1994).Para o desenvolvimento de um ambiente de execução Java em uma ediçãoJava ME, é obrigatória a escolha de uma configuração e um perfil. No entanto,podem ser adicionados pacotes extras de acordo com o critério do fabricante,como mostrado na Figura 10. A figura mostra a criação de um ambiente onde foiescolhida a configuração CDC, o perfil PBP, mais o pacote opcional JSSE (JavaSecure Sockets Extension), para realizar conexões de rede seguras.Figura 10 – Exemplo de ambiente de execução Java.A construção do ambiente de execução Java mínimo para TV digital émuito semelhante ao exemplo citado anteriormente. Apresenta a configuraçãoCDC, o perfil PBP (sendo que o PP é permitido) e algumas bibliotecas opcionais.A soma do PBP com o CDC mantém, ainda, a compatibilidade com oPersonalJava (uma configuração de máquina virtual Java prevista no GEM/MHPe cuja normalização foi descontinuada sendo substituída pelo CDC/CLDC).

Conceitos Preliminares 43No GEM, por se tratar de um ambiente de TV e por ser um acordo deharmonização, algumas bibliotecas tornaram-se obrigatórias. Dentre elas, abiblioteca Java TV introduz o modelo de programação Xlet.• download de conteúdos e aplicações novas.2.4.1.O Modelo de programação XLETO modelo de programação Xlet é voltado para aplicações desenvolvidaspara sistemas de TV Digital. Nesse modelo é possível realizar um controle dociclo de vida dessas aplicações através de uma interface Java, mostrada na Figura12, por elas implementada. As diversas entidades envolvidas nesse modelo, e oprotocolo de comunicação entre elas, são mostrados na Figura 11.Os Xlets, como são conhecidas as aplicações, podem ser lançadosautomaticamente, via sinalização, ou iniciados através da navegação pelo controleremoto dos telespectadores. Eles podem encontrar-se residentes no receptor, serextraídos do carrossel de objetos e dados de um fluxo DSM-CC (ISO, 1998), ouser obtidos pelo canal de retorno.

Conceitos Preliminares 44Figura 11 – Protocolo entre as entidades presentes no modelo e programação Xlet.O Gerenciador de Aplicações (Application Manager) é a entidaderesponsável pelo carregamento e o controle direto do ciclo de vida dos Xlets. Eledever ser capaz de interpretar os dados provenientes da AIT (ou seja, localizaçãoda aplicação, classe inicial etc.) para, de acordo com aqueles recebidos, gerenciara execução das aplicações. Através de um mecanismo conhecido como caching, oGerenciador de Aplicações mantém uma tabela onde monitora as mudanças deestado e recomeça a execução de Xlets presentes no receptor. O Gerenciador deAplicações é parte do sistema e reside no receptor.No modelo de programação Xlet, as aplicações devem implementar ainterface mostrada na Figura 12. A classe Java que implementar essa interface é aporta de entrada no aplicativo. Ela possuirá métodos que refletem diretamente osestados do ciclo de vida de um Xlet.public interface Xlet {public void initXlet(XletContext xtx)throws XletStateChangeException;public void startXlet()throws XletStateChangeException;public void pauseXlet();public void destroyXlet(boolean unconditional)throws XletStateChangeException;}Figura 12 - Interface do Xlet.Uma aplicação Xlet poderá encontrar-se nos estados ilustrados pela máquinade estados da Figura 13. Quando a classe Java inicial de uma aplicação écarregada, do carrossel de objetos ou do receptor, e instanciada, ela entra noestado Loaded (carregada). O estado Loaded significa que a aplicação já foicarregada, mas ainda não foi iniciada. No momento seguinte o Gerenciador deAplicações sinaliza o Xlet para que ele seja iniciado (chamando seu método“initXlet”). Após iniciado ele entra no estado Paused (pausado). Uma aplicaçãono estado Paused está minimizando o uso de recursos para maximizar suasobrevivência, e está pronta para executar. No estado Active, a aplicação estáfuncionando plenamente, e no estado Destroyed já liberou todos os recursos eterminou sua execução.

Conceitos Preliminares 45Figura 13 - Máquina de estados do ciclo de vida de um Xlet.Além dos Xlets e do Gerenciador de Aplicações, existe o Contexto ouXletContext. Todo Xlet possui um contexto associado, ou seja, uma instância daclasse javax.tv.xlet.XletContext. Isso é similar à classe AppletContext que éassociada a um applet.O XletContext é uma interface Java (mostrada na Figura 14) cujaimplementação é fornecida pelo Gerenciador de Aplicações. Através dessainterface, o Gerenciador de Aplicações pode controlar o estado de um Xlet, tendoa capacidade de encerrar sua execução a qualquer momento. O Xlet pode, ainda,utilizar o XletContext para acessar propriedades do receptor ou realizar umamudança em seu estado.public interface XletContext {public static final String ARGS = javax.tv.xlet.args”;public void notifyPaused();public void notifyDestroyed();public resumeRequest();}Figura 14 – Interface do XletContext.Na requisição de mudança de estado iniciada pelo Xlet, ele notifica seu novoestado desejado ao Contexto. A partir daí, o Gerenciador de Aplicações énotificado e, em seguida, realiza a mudança do estado do Xlet. Utilizando essemecanismo de callback, o Gerenciador de Aplicações pode manter atualizado ostatus dos Xlets por ele controlados. Portanto, o Contexto é uma ponte decomunicação entre o Xlet e o Gerenciador de Aplicações.

Conceitos Preliminares 46Os métodos “notifyDestroyed” e “notifyPaused” permitem ao Xlet notificaro terminal sobre a possibilidade de terminá-lo ou pausá-lo. O Xlet pode usar essesmétodos para ter certeza que o terminal sabe o estado de toda aplicação e podetomar a ação apropriada. Esses métodos devem ser chamados imediatamenteantes do Xlet entrar nos estados de Paused ou Destroyed, isto porque o terminalpode tomar uma ação que a aplicação não esteja preparada.Uma aplicação pode requisitar a mudança do estado Paused para o Startedusando o método “resumeRequest”. Isso acontece quando um determinado eventooccorreu, como, por exemplo, um tempo certo foi atingido, um evento certo foidetectado num fluxo MPEG, etc. Com esse método, é possível reiniciar umaaplicação após esta ter sido suspensa.

3Trabalhos RelacionadosAs propostas para ambientes de apresentação declarativos compatíveis comsistemas que implementem o GEM são relativamente recentes. A própriaespecificação MHP, como já mencionado, em sua primeira versão não previa umambiente dessa natureza, assim como o padrão OCAP que até hoje não o prevê.As linguagens declarativas adotadas pela maioria dos padrões internacionaissão baseadas no XHTML. Neste capítulo será mostrada uma proposta de umsistema escrito na linguagem procedural DVB-J e que permite a apresentação dedocumentos XHTML.Dadas as limitações impostas pela linguagem XHTML, discutidas noApêndice C, surgiram na Europa duas propostas para a implementação de umambiente declarativo, para sistemas que implementam o GEM, utilizando alinguagem SMIL (W3C, 2005). Uma delas trata de uma implementação realizadapelo Laboratório de Multimídia e Software para Telecomunicações daUniversidade de Tecnologia de Helsinki (Lamandon et al, 2003); e a segunda fazparte de um projeto da Information Society Technologies (IST) buscandoinvestigar formas de melhorar a interatividade com o usuário por meio do avançotecnológico provocado pelo DVB-MHP, internet e MPEG4 (Fuhrhop et al, 2003).Neste capítulo é apresentado, ainda, o Formatador NCL, isto é, a máquinade apresentação de documentos especificados na linguagem NCL, que é utilizadacomo base para o desenvolvimento desta dissertação.Para cumprir seus propósitos o capítulo está organizado da forma a seguir.A Seção 3.1 apresenta um sistema que permite o processamento de documentosXHTML por receptores MHP. A Seção 3.2 apresenta o ambiente declarativodesenvolvido pela UTH. E, por fim, a Seção 3.3 apresenta o ambiente declarativopara TV Digital desenvolvido pelo projeto da IST.

Trabalhos Relacionados 483.1.O MHP Processando Documentos XHTMLDado que o DVB-HTML não se encontra implementado a contento e deforma a permitir o reaproveitamento do conteúdo presente na Web paraapresentação em sistemas de TV Digital, pesquisadores do Departamento deCiência da Computação da Universidade de Bologna propuseram um sistemacapaz de processar conteúdos dessa natureza em receptores MHP (Ferretti et al,2006).diferentes:A proposta consiste em uma arquitetura compreendendo dois componentes• um serviço automático de transcodificação, mostrado na Figura 15,capaz de converter o conteúdo da Web (no formato HTML) paraXHTML e repassá-lo para a difusora (para a inserção no carrosselDSM-CC); e• uma aplicação DVB-J capaz de extrair o conteúdo do carrossel eexibí-lo.Figura 15 – Arquitetura da proposta do transcodificador.A estratégia de transcodificação utilizada consiste em, num primeiromomento, converter o documento de HTML para XHTML Básico que é maisfacilmente processado por clientes de baixo desempenho. O segundo estágioconsiste em remover do documento XHTML elementos que não podem servisualizados na TV, reduzindo o tamanho do documento. E, finalmente, é feitoum processamento dos objetos referenciados (inclusive por elos) por essedocumento de forma a torná-los disponíveis no ambiente do cliente.

Trabalhos Relacionados 49A proposta realiza ainda algumas adaptações para uma melhor navegaçãopelo documento:• são eliminadas as barras de rolagem. Assim, caso o documentoutilize uma área maior que a tela do usuário para sua exibição, aaplicação DVB-J divide o documento em páginas; e• é criado um novo frame no topo a direita onde são organizados oselos presentes no documento.Dessa forma, quando o usuário utiliza as teclas direcionais para esquerda edireita navega pelas páginas, e quando utiliza as teclas para cima e para baixonavega pelos elos.O sistema foi testado em dois ambientes de simulação (o XletView e oOpenMHP) e em um ambiente DVB-T real. No entanto, o trabalho não mencionadados importantes como o tamanho da aplicação DVB-J criada, ou o retardo paraa iniciação da apresentação do documento. É mencionado apenas que o protótiporeduz efetivamente o tamanho dos documentos HTML convertidos.3.2.Ambiente declarativo para TV Digital – UTHA solução consiste no uso de uma máquina de apresentação de documentosSMIL sobre uma implementação de um sistema de TV Digital denominadoOtadigi. Esse sistema é baseado no padrão europeu DVB, utilizando paratransmissão o DVB-T e como middleware o MHP. Dada sua configuração deparâmetros de telecomunicações, como modulação, canal, taxa de codificação eguard-interval, permite transferências a uma taxa de bits de cerca de 13,27 Mbps.Devido às características do middleware, a máquina de apresentação foidesenvolvida na linguagem JAVA, sendo utilizada a biblioteca gráfica FTV, que ébaseada no HAVI, para construir os elementos de interação com o usuário.Para a implementação do sistema foi necessário levar em consideraçãorestrições impostas pelos requisitos de um sistema de TV digital. Originalmente, alinguagem SMIL não oferece suporte a eventos de interação por controle remoto,apenas via mouse. Para resolver esse problema, os links são mapeados em botõesFTV. Quanto à questão da navegação, foi incluído ainda um novo atributo noslinks para identificar suas características: actionable para links acionados por

Trabalhos Relacionados 50botões coloridos; e focusable para links que serão acessados pelas teclas denavegação.Para o cenário de testes foram criados dois programas diferentes: umteletexto digital e um programa de futebol. O conteúdo das apresentações foiacessado por 3 meios diferentes: pelo canal de broadcast, utilizando uma banda de3Mb/s do sistema Otadigi; por um modem analógico de 56Kb/s; e por umacombinação dos dois (canal de broadcast para o conteúdo genérico e o modempara o específico/personalizado).O tamanho da máquina de apresentação totalizou cerca de 1,4 MB. Noambiente de testes utilizado isso acarretou um tempo de carregamento (downloadpara memória local) de 19 segundos e um tempo de iniciação de 7 segundos. Partedesse atraso se deve à utilização de uma biblioteca XML que ocupa cerca de 66%do espaço da máquina de apresentação.O estudo apontou ainda o uso do modem analógico como um ponto fraco dosistema. O modem foi testado como forma de avaliar a viabilidade dedisponibilizar parte dos recursos necessários à apresentação via um canal deretorno. No entanto, o uso de tal recurso chegou a gerar um atraso de 100segundos em relação ao uso apenas do canal de broadcast.O uso dessa solução mostrou ser necessário:• uma otimização da biblioteca XML, salvo no caso da utilização emum sistema MHP 1.1 que já prevê tal biblioteca nativamente;• se possível, a integração da máquina de apresentação SMIL aoreceptor, para diminuir o tempo de carregamento do player;• a criação de métodos para utilização de stream events parasincronizar a máquina de apresentação SMIL com o fluxotransmitido.3.3.Ambiente declarativo para TV Digital – ICECREAMICECREAM visa levar a interatividade com o usuário a um nível maisavançado. Para isso, foi proposto o uso das tecnologias oferecidas pelomiddleware DVB-MHP, a Internet e o padrão MPEG-4.

Trabalhos Relacionados 51A solução desenvolvida pelo projeto, que faz uso do SMIL, prevê o acesso àInternet pelo canal de retorno do receptor. Nessa solução, a interpretação dodocumento SMIL é feita por um Xlet interpretador que cuida de todo controle detemporização e leiaute informado no documento. O uso do SMIL se dá de forma aintegrar o vídeo principal com recursos interativos adicionais e personalizados viaum provedor de serviço na Internet.Para prover um nível maior de interatividade, o documento SMIL émoldado de acordo com o perfil de preferência do usuário que está requisitando oserviço em tempo de apresentação. Essa customização do documento ocorreatravés da interpretação dos parâmetros presentes na query HTTP da requisiçãofeita pelo receptor ao provedor de conteúdo. O processo ocorre, basicamente, damesma forma como é feito para documentos HTML dinâmicos.Como referência, é apresentada no projeto a implementação de umprograma que mostra uma orquestra em um concerto de música clássica. Ainteratividade ocorre através da criação de um documento SMIL que possibilita ofornecimento de informações sobre o compositor da obra, o condutor da orquestrae a sala do concerto (programação, compra de ingresso). A personalização nestecaso é feita, por exemplo, através do oferecimento de informações deprogramação de casas de concerto na região geográfica específica dotelespectador.No projeto não são apresentados dados referentes ao desempenho dosistema proposto.

4O Fomatador NCLO Formatador NCL compõe a máquina de apresentação de documentosNCL. Ele é o elemento responsável por receber a especificação de umhiperdocumento (sua estrutura, seus relacionamentos e a descrição da forma deexibição desejada) e concretizá-la na apresentação propriamente dita (Rodrigues,2003).No entanto, a implementação Java do Formatador NCL é voltada para aplataforma Java SE. Para que essa implementação possa executar com ocomportamento esperado em sistemas de TV digital, são necessárias algumasadaptações e otimizações a serem discutidas neste capítulo.Para cumprir seus propósitos o capítulo está organizado da forma a seguir.A Seção 4.1 faz uma breve descrição da versão Java do Formatador NCL. ASeção 4.2 sugere uma otimização no método utilizado pelo Formatador paraleitura e conversão do documento NCL. A Seção 4.3 sugere o desmembramentodo Formatador em componentes de software. E, por fim, a Seção 4.4 sugerealgumas mudanças nos em cada módulo do formatador.4.1.O Formatador NCL JavaA implementação Java atual do Formatador pode ser estruturada emmódulos como mostrado na Figura 16. Para realizar suas tarefas, talimplementação conta com o auxílio do conversor, do escalonador e informaçõessobre o contexto de execução. Além dessas entidades, o Formatador faz uso dosserviços oferecidos por mais três elementos: o Gerenciador de Leiaute, oGerenciador de Documentos e o Gerenciador de Adaptadores para Exibidores.

O Fomatador NCL 53Figura 16 – Arquitetura do Formatador NCL.O processo de apresentação se inicia quando o Formatador recebe umcomando de edição específico para iniciar a apresentação de um documento. Apartir desse comando, o Formatador requisita os serviços do Gerenciador deDocumentos.O Gerenciador de Documentos tem a responsabilidade de processar oscomandos de edição delegados pelo Formatador e realizar a manutenção dosdocumentos NCL ativos em uma base de documentos. Ao receber um comandode edição, o gerenciador poderá: realizar operações sobre a base de documentos(ex.: exclusão de documento, exclusão de um elo em um documento, entreoutras); ou, caso o comando de edição contenha especificações XML (porexemplo, para adição de documentos, elos, conectores, entre outros) (Soares et al.,2006), o Conversor NCL é acionado.O Conversor NCL é a entidade responsável por transformar especificaçõesXML em entidades do modelo conceitual NCM. São essas entidades que poderãoser, efetivamente, armazenadas na base de documentos pelo Gerenciador deDocumentos.As entidades inseridas na base de documentos estão aptas a seremapresentadas. Para iniciar esse processo, no entanto, é preciso convertê-las para o

O Fomatador NCL 54modelo de execução interno do Formatador. Isso é feito através do Conversor doModelo de Execução.Essa segunda conversão é realizada sob demanda. O critério utilizado é adistância, contada em elos, a partir do objeto de mídia em execução, ou seja, àmedida que novos objetos de mídia são executados, aqueles a uma certa distânciaserão compilados. Cabe ressaltar que essa distância é um dos parâmetros deconfiguração do Formatador.Outra entidade envolvida no processo de apresentação é o Escalonador. Àmedida que novos elos causais são adicionados ao modelo, o Formatador notificatal entidade. A partir daí, o Escalonador se cadastra como observador de tais elospara receber uma notificação quando a condição prevista nestes for satisfeita.Quando, enfim, o Escalonador receber a notificação do elo, este executará a açãopor ele representada.O Formatador tem, ainda, a responsabilidade de emitir notificações quandonovos objetos de execução são adicionados ao seu modelo de execução. Cadaobjeto de execução representa a instância de um nó a ser exibido, especificado nodocumento NCL, contendo todas as suas informações, inclusive as suascaracterísticas de apresentação provenientes do descritor de apresentaçãoassociado. Quando esse descritor existir, o Gerenciador de Leiaute, se necessário,cria a superfície para a exibição do conteúdo do nó.Ainda no momento em que novos objetos de execução são adicionados, éfeita uma avaliação das alternativas de objetos que podem ser resolvidasestaticamente. São avaliadas as informações do contexto de execução(preferências do usuário, poder de processamento, recursos disponíveis) para que,a partir das regras definidas no documento, seja feita a escolha do objeto deexecução adequado.Mais adiante, no momento em que o Escalonador requisita a execução deum objeto de mídia, ocorre a interação de mais um módulo do Formatador: oGerenciador de Adaptadores para Exibidores. Esse gerenciador tem à suadisposição um conjunto de adaptadores para os exibidores que tratamdeterminados tipos de conteúdo suportados pelo ambiente do Formatador NCL. Apartir do objeto de execução, o gerenciador seleciona o adaptador de um exibidorcapaz de reproduzir o conteúdo de tal objeto.

O Fomatador NCL 55Como exemplo de exibidores pode-se citar: XHTML, LUA, imagensestáticas (JPEG, PNG, GIF), áudio (WAVE, MPEG-1, MPEG-2) e vídeo (MPEG-1, MPEG-2).4.2.O GEM processando um documento NCLComo visto na Seção 4.1, o primeiro passo para a execução de umdocumento NCL é a sua conversão de uma especificação XML para objetos JavaNCL. Essa operação consome tempo, processamento e espaço no receptor paraarmazenar uma biblioteca que realize a tradução do documento XML. Essesrequisitos levam à elaboração de dois cenários diferentes para tratar o processo deconversão: a pré-conversão do documento e a conversão no receptor.No primeiro cenário, a conversão ocorre no provedor de conteúdo. Nessecaso, ao invés de receber documentos NCL, os receptores processariamdiretamente objetos Java serializados 2 , tornando opcional a presença de umabiblioteca capaz de processar documentos XML. Esse cenário é mais indicado napresença de um receptor com recursos de processamento/memória bastanteescassos. Contudo, os receptores que se basearem nesse modelo perderão acapacidade de processar diretamente documentos NCL. Eles não seriam capazesde atuar em cenários onde lhes fosse exigido, por exemplo, processar documentosNCL dinâmicos presentes na WEB via canal de retorno. Sua capacidade deprocessamento restringir-se-ia apenas a objetos serializados.Na Figura 17 é ilustrado esse processo de pré-conversão do documento NCL.Nele o documento é convertido pelo provedor de conteúdo, depois é serializado eenviado para o carrossel de objetos para, em seguida, ser desserializado eprocessado pelos receptores.2 A serialização de objetos JAVA permite a codificação de um objeto e de todos os objetospor ele referenciados direta ou indiretamente em um fluxo de bytes. Permite ainda a reconstruçãodo “grafo” de objetos a partir de um fluxo. Este fluxo possibilita o envio por rede e oarmazenamento em arquivos, por exemplo.

O Fomatador NCL 56Figura 17 – Pré-processamento do documento NCL.No segundo cenário, a conversão ocorre no receptor. Esse cenário éantagônico ao primeiro: requer um receptor com um maior poder deprocessamento/armazenamento e permite o processamento de documentos NCLem seu estado bruto. A Figura 18 ilustra esse processo em que o documento éenviado para o carrossel de objetos sendo convertido apenas no ambiente dosreceptores.Figura 18 – Processamento do documento NCL no receptorEssa é a forma convencional de operação do Formatador NCL. Ela requer,da parte do receptor, a presença de uma biblioteca para o processamento dearquivos XML.

O Fomatador NCL 574.3.A Arquitetura de ImplantaçãoNa Seção 4.1 foi mostrado o caráter modular da arquitetura do FormatadorNCL. Essa característica possibilita a realização de otimizações em seu processode implantação. Os seguintes módulos podem ser identificados:• Núcleo do Formatador, formado pelo Formatador e compreendendoo Escalonador, o Conversor e as Informações do Contexto;• Gerenciador de Leiaute;• Gerenciador de Documentos; e• Gerenciador de Adaptadores para Exibidores. Sendo que cadaexibidor por ele gerenciado constitui um módulo específico.Cada módulo abrange um componente de software diferente. Essescomponentes serão enviados para os receptores para a reprodução do documentoNCL. Contudo, apenas os módulos necessários em um dado cenário deverão sercarregados.Caso o receptor forneça a capacidade de armazenamento de aplicações, épossível otimizar-se o tempo de iniciação do Formatador ao armazenar localmenteos módulos comumente utilizados. No entanto, algum mecanismo de controle deversão torna-se necessário, afim de evitar problemas de compatibilidade e suportea atualizações dos módulos.4.3.1.Estrutura do Sistema Baseada em ComponentesAo modelar o Formatador NCL de forma a baseá-lo em componentes desoftware, estes devem compor unidades binárias desenvolvidas de formaindependente que cooperem através de interfaces bem definidas (Szyperski,2002). Têm-se, assim, as seguintes vantagens:• Capacidade de reutilizar esses componentes em outras aplicações.Ou seja, um mesmo componente ser utilizado para TV, desktop,ferramentas de autoria ou até outro tipo de aplicação de formaindependente;• Fácil manutenção e customização desses componentes para oferecernovas funcionalidades e recursos. Ou seja, alguns componentes

O Fomatador NCL 58podem sofrer customizações individualmente, como, por exemplo,para IPTV (Weber & Newberry, 2006);• Possibilidade de fornecer unidades de implantação (deployment)independentes; e• A linguagem de programação de cada componente não precisa sernecessariamente a mesma.No entanto, em sistemas GEM não se pode tirar proveito de todas asvantagens citadas. Seu ambiente, por exemplo, permite apenas uma linguagem deprogramação. Além disso, devido ao fato do programa ter como requisito anecessidade de operar em uma plataforma com recursos limitados, nenhumframework/infra-estrutura de componentes (como, por exemplo, CORBA CCM)deve ser utilizado para a implementação dos mesmos. Porém, é válido para aelaboração do sistema o uso dos conceitos de componentes independentes deinfra-estruturas comerciais adotadas (Brown & Wallnau, 1999), tornando possíveluma futura adoção de tais infra-estruturas, como sugerido na Seção 6.1.4.4.Adaptações e Otimizações no Formatador NCLO primeiro aspecto a levar em consideração na implementação doFormatador NCL Xlet é que este deve utilizar apenas as bibliotecas fornecidaspelo JVM mínimo necessário para o GEM, ou seja, portar o código escrito parauma configuração de máquina virtual Java SE para uma configuração Java ME(CDC com PBP). A seguir são abordados aspectos particulares de cadacomponente.4.4.1.A Pré-conversão de Documentos NCL e o Módulo Gerenciador deDocumentosO conversor de documentos NCL está contido dentro do móduloGerenciador de Documentos. Ele é responsável por converter os documentosNCL (descritos no formato XML) em objetos Java. Esse processo, no entanto,requer a presença de uma biblioteca XML capaz de traduzir tais documentos.Num ambiente de TV Digital, a adição de tal biblioteca ocupa tempo de

O Fomatador NCL 59transmissão e, conseqüentemente, ocasiona um maior retardo na iniciação daapresentação.A solução proposta na Seção 4.2 prevê a criação de um ambiente de préconversãode documentos NCL. No entanto, de forma a não alterar a interfacefornecida pelo Componente Gerenciador de Documentos e, ainda assim, permitira pré-conversão, optou-se por adotar o seguinte processo. No ambiente de préconversão(no produtor de conteúdo, por exemplo), o Gerenciador de Documentosé instanciado. Em seguida, todos os documentos necessários para a apresentaçãosão convertidos e adicionados à sua base de documentos. Ao final do processo, ocomponente é serializado e enviado aos receptores. Dessa forma, elimina-se anecessidade do envio da biblioteca XML para o receptor tornando, porém, oGerenciador de Documentos incapaz de processar comandos de edição NCL quenecessitem da conversão de especificações XML.Esse cenário leva à criação de um padrão de apresentação de DocumentosNCL Orientados a Sincronização por Contexto. Nesse padrão, o produtor deconteúdo criará vários contextos (composições ou documentos) que serão préconvertidose enviados para os receptores no componente Gerenciador deDocumentos serializado antes do início da apresentação. No momento desejado, aemissora enviará um comando de edição para a iniciação do contexto. Éimportante notar que os documentos desse padrão caracterizam-se por possuirvários contextos sem elos definidos entre eles.O exemplo mostrado na Figura 19 ilustra a transmissão de uma partida defutebol seguindo o padrão de apresentação de Documentos NCL Orientados aSincronização por Contexto. Primeiramente, é enviado o Gerenciador deDocumentos juntamente com todos os contextos envolvidos na apresentação dapartida de futebol (no caso, os dois documentos com os identificadores “Futebol”e “intervalo”). A seguir, é enviado um comando de edição NCL do tipostartDocument para iniciar a exibição do documento “Futebol”. Durante o jogo éenviado o mesmo comando no momento em que ocorre o gol de alguma dasequipes, iniciando a exibição de um contexto responsável por mostrar umaanimação comemorativa. Ao longo do jogo, podem ser enviados outros comandose pode ser acionado o início da exibição de um outro documento pré-convertido,representado na Figura 19 pelo identificador (“id”) “intervalo” e que representa aapresentação do intervalo de jogo.

O Fomatador NCL 60Figura 19 – Modelo de uma apresentação NCL orientada a sincronização por contexto.Quando não houver a necessidade de pré-conversão, o componenteGerenciador de Documentos poderá ser instanciado no receptor. Este é o caso, porexemplo, de receptores que já possuam nativamente uma biblioteca para atradução de documentos XML, ou, ainda, sistemas que possibilitem a persistênciade dados.4.4.2.Adaptações do Módulo do Núcleo do FormatadorA porta de entrada para este componente é a entidade que implementa ainterface IFormatter. Atualmente, essa interface encontra-se especificada deacordo com o diagrama da Figura 20. A figura mostra que essa interface éresponsável por:• Processar comandos para o controle da apresentação, como reset(reiniciar), close (fechar), startDocument (iniciar a apresentação deum documento a partir de uma âncora), stopDocument (finalizar aapresentação de um documento), pauseDocument (pausar aapresentação de um documento) resumeDocument (continuar aapresentação de um documento);

O Fomatador NCL 62Figura 20 – Digrama de classe da interface IFormatter.Assim, caso o Núcleo do Formatador ofereça suporte a eventos de ediçãobasta que, internamente, alguma entidade implemente a interface representada nodigrama da Figura 21 e se cadastre como Listener do Gerenciador deDocumentos. No momento que um documento for alterado por um comando deedição todos os Listeners serão notificados.

O Fomatador NCL 64Gerenciador de Adaptadores a localização e o protocolo para a obtenção doadaptador.Os adaptadores criados para a validação da implementação foram o detexto, o de imagens estáticas e o NCLet. Esse último, em especial, é responsávelpor realizar a ponte com o ambiente procedural. O conteúdo de sua exibição sãoprogramas descritos em código binário Java.4.4.4.Adaptações do Módulo Gerenciador de LeiauteNo modelo utilizado pelo Formatador NCL, a construção da interfacegráfica, ou seja, os componentes gráficos onde os objetos de mídia serão exibidos,é feita pelo Gerenciador de Leiaute.Este componente fornece a implementação para duas entidades: oIFormatterLayout que, de fato, gerencia o leiaute; e o IFormatterRegion quecontém a informação do elemento da interface gráfica em si.A Figura 22 mostra o diagrama de classes do módulo de leiaute, introduzidopelo Formatador, apresentando uma modificação: a adição do métodocreateRegion na interface IFormatterLayout. Dessa forma, as regiões serãocriadas apenas a partir de seu gerenciador, permitindo que este mantenha umareferência para todas aquelas criadas.Diferente do ambiente do desktop, o perfil PBP da configuração CDC nãooferece suporte à biblioteca gráfica SWING (Robinson & Vorobiev, 2003),apenas AWT (Geary & McClellan, 1997). Nesse perfil, é permitida apenas acriação de uma única janela (Frame). Com isso, a implementação da classeIFormatterRegion, responsável por criar os elementos de interface gráfica, foialterada para atender tais requisitos.

O Fomatador NCL 65Figura 22 – Diagrama de classes do modelo de leiaute do Formatador NCL.

5O Fomatador NCL XletAtualmente, o Formatador NCL encontra-se implementado em duaslinguagens: JAVA e C++. Com o GEM oferecendo um ambiente JAVA para aexecução global de aplicações interativas, tem-se a possibilidade de portar aimplementação do Formatador para sistemas que implementem tal framework.No entanto, a implementação Java do Formatador NCL é voltada para aplataforma Java SE. Para que ela possa executar com o comportamento esperadoem sistemas de TV digital, são necessárias algumas adaptações e otimizações aserem discutidas neste capítulo.Para cumprir seus propósitos este capítulo está organizado da forma aseguir. A Seção 5.1 detalha como desmembrar a arquitetura do Formatador emcomponentes independentes e as possíveis otimizações que podem ser realizadasnessa arquitetura. A Seção 5.2 trata da implementação do ambiente a partir daspropostas das seções anteriores e descreve o processo de implantação(deployment) do sistema proposto nesta dissertação. Ao final da seção, sãoapresentados mecanismos para a integração desse mesmo sistema com o padrãoMHP. E, por fim, a Seção 5.3 apresenta o ambiente onde foram realizados ostestes da implementação.5.1.Os Componentes do Formatador NCL XletNas seções a seguir serão descritos os componentes que compõem oFormatador NCL.

O Fomatador NCL Xlet 675.1.1.Gerenciador de LeiauteFigura 23 – Duas implementações do componente Gerenciador de LeiauteEsse componente é responsável por controlar a interface gráfica doFormatador. Ele possui a capacidade de criar as regiões onde serão exibidos osobjetos de mídia. Por esse motivo ele deve sofrer uma customização para cadaambiente gráfico (como X Window System) (Scheifler & Gettys, 1996) no qualtais objetos serão exibidos.A interface fornecida por esse componente é a IFormatterLayout, descritana Seção 4.4.4, e as interfaces necessárias para sua execução irão depender daimplementação. A Figura 23 ilustra duas implementações diferentes dessecomponente: uma para desktops e outra customizada para TV. Na implementaçãopara TV percebe-se a necessidade da interface IGingaXletConfiguration. Maioresdetalhes sobre essa interface e essa implementação são encontrados na Seção4.4.4.Esse componente não é obrigatório. Apesar de na maioria das vezes haver anecessidade de seu uso, em apresentações onde for necessário apenas osincronismo entre objetos de mídia do tipo áudio, não há a necessidade docarregamento desse componente.

O Fomatador NCL Xlet 685.1.2.Gerenciador de DocumentosFigura 24 – Componente Gerenciador de Documentos.Esse componente é responsável por gerenciar uma base de documentos.Nesse processo o componente irá adicionar, remover e alterar os documentos dabase. Dentre outras coisas, o componente Gerenciador de Documentos é capaz dereceber a especificação de documentos XML, verificar se estes possuem umasintaxe/semântica NCL válida e convertê-los para objetos Java. Para realizar esseprocesso, o componente necessita da presença de uma biblioteca capaz deprocessar documentos XML. Basicamente, o componente é formado pelasseguintes entidades, mostradas na Figura 16: Gerenciador de Documentos,Conversor NCL e a Base de Documentos.O recebimento de documentos XML é feito através da interfaceINCLDocumentManager, mostrada na Figura 24. O conjunto de métodosprovidos por essa interface permitem ao componente processar os Comandos deEdição NCL.A necessidade desse componente vai depender da implementação docomponente do Núcleo do Formatador. Uma implementação mais simples denúcleo que, por exemplo, processe apenas um documento (incluindo osdocumentos por ele referenciados) por vez e não dê suporte a eventos de ediçãoNCL não necessitaria desse componente.

O Fomatador NCL Xlet 695.1.3.Núcleo do FormatadorFigura 25 – Duas implementações do componente do núcleo do formatador.Dos componentes apresentados esse é o mais importante e obrigatório. Eleserá o responsável por controlar a apresentação e corresponde diretamente aonúcleo do Formatador mostrado na Seção 3.4.Esse componente pode ter sua implementação customizada de forma asimplificar o seu funcionamento. Como mostrado na Figura 25, pode-se criar umaimplementação simples de Núcleo independente do Gerenciador de Documentos.Esse componente depende ainda das interfaces IFormatterLayout (oferecida peloGerenciador de Leiaute) e IPlayerAdapterManager (oferecida pelo Gerenciadorde Adaptadores para Exibidores, que será visto na seção a seguir).De acordo com as otimizações propostas na Seção 4.4.2, a interfaceIFormatter possui a assinatura mostrada na Figura 26.Figura 26 – Duas implementações do componente do núcleo do formatador

O Fomatador NCL Xlet 705.1.4.Gerenciador de Adaptador para ExibidoresFigura 27 – Duas implementações do componente Gerenciador de ExibidoresEsse componente é obrigatório para a execução do Formatador NCL. Agestão realizada por ele compreende a identificação e instanciação do adaptadorpara o exibidor necessário para a apresentação de um determinado tipo deconteúdo.Assim como o Gerenciador de Leiaute, esse componente apresenta umaforte dependência com o ambiente no qual será executado (TV, Desktop). Issoporque, além de, no caso de exibidores de vídeo ou imagens, haver umadependência quanto à interface gráfica do ambiente, a forma como são obtidos osrecursos (no caso, os exibidores) depende do ambiente de execução. Num sistemade TV Digital, por exemplo, os recursos podem estar presentes no carrossel deobjetos DSM-CC, sistema de arquivos local ou canal de retorno. O mecanismoutilizado para identificação de recursos num sistema GEM é tratado na Seção 4.3.5.1.5.Adaptadores para ExibidoresFigura 28 – Duas implementações de adaptadores para exibidores.

O Fomatador NCL Xlet 71Esse componente constitui uma camada de adaptação para exibidores de umdeterminado tipo de conteúdo de forma a torná-los compatíveis com o modelo deexecução do Formatador NCL. Existe uma implementação diferente dessecomponente para cada exibidor suportado pelo formatador.Na apresentação de um dado documento NCL nem todos os exibidoresdisponíveis para o Formatador NCL são necessariamente utilizados. Existem, porexemplo, apresentações que envolvem apenas imagens estáticas, outras apenastextos. Dessa forma, a obrigatoriedade desse componente depende do tipo deconteúdo por ele processado e a presença desse conteúdo na apresentação.Para tornar esse componente independente do protocolo utilizado para aobtenção do conteúdo a ser exibido, utiliza-se as facilidades oferecidas pelainterface IGingaXletDeployer para o carregamento de arquivos. Isso porque, porexemplo, antes de obter um arquivo de um carrossel DSM-CC, é necessárioestabelecer uma conexão. A interface IGingaXletDeployer abstrai todas essaspeculiaridades. Mais informações sobre o funcionamento dessa classe podem serencontradas na Seção 5.2.2 e 5.2.3.5.2.Implementação dos Componentes para Sistemas GEMEsta seção e suas subseções descrevem a implementação do ambiente deexecução declarativo, baseado na linguagem NCL. Esta implementação é baseadana implementação Java do Formatador NCL. A partir dela são feitas adaptaçõespara adequá-la às propostas das Seções 4.1, 4.2 e 4.3.O primeiro aspecto a levar em consideração na implementação doFormatador NCL Xlet é que este deve utilizar apenas as bibliotecas fornecidaspelo JVM mínimo necessário para o GEM, ou seja, portar o código escrito parauma configuração de máquina virtual Java SE para uma configuração Java ME(CDC com PBP). A seguir são abordados aspectos particulares de cadacomponente.

O Fomatador NCL Xlet 725.2.1.O Carregamento DinâmicoA chave para a criação de uma arquitetura modular, onde os módulospodem ser carregados dinamicamente no decorrer da execução da aplicação, é ouso das tecnologias oferecidas pelas classes java.lang.Class ejava.lang.ClassLoader.Cada classe Java disponível para uso por uma aplicação é carregada por umobjeto ClassLoader a ela associado. Ou seja, quando o Gerenciador deAplicações, abordado na Seção 2.4, inicia a execução do Xlet, todas as classesdisponíveis para uso por este Xlet estão associadas a um ClassLoader uilizadopara carregá-las inicialmente em memória. Ao longo da execução da aplicação,esta instância de ClassLoader pode ser usada para o carregamento de novasclasses que antes não se encontravam disponíveis para o uso pela aplicação. Aeste processo dá-se o nome de Dynamic Class Loading (Liang & Bracha, 1998),ou Carregamento Dinâmico de Classes.O carregamento dinâmico de classes não se restringe apenas às classespresentes no ambiente de execução da aplicação. É possível carregar classesdisponíveis em ambientes remotos através da transferência do código bináriodestas classes via protocolos de rede. A classe java.net.URLClassLoaderutiliza, por exemplo, uma conexão baseada no protocolo especificado via URL(desde que implementado pelo ambiente de execução Java local) para transferir ecarregar o código binário das classes. O carregamento dinâmico ainda traz umbenefício denominado lazy loading: ao atrasar o carregamento o máximo possível,ocorre uma economia de memória e uma melhora no tempo de resposta dosistema. Isso porque a classe só é carregada quando requisitado e não nainicialização do sistema.A partir do momento em que a classe encontra-se disponível para uso, pornão possuir uma referência estática, seu referenciamento e instanciação deverãoocorrer de forma dinâmica, ou seja, para obter uma referência para a nova classeutiliza-se o método estático “forName” da classe java.lang.Class passandocomo parâmetro o nome da classe a ser instanciada. Este método retornará umainstância da classe java.lang.Class. Com esse objeto pode-se, finalmente,

O Fomatador NCL Xlet 73criar uma instância da classe (dinamicamente carregada) através do método“newInstance”.No sistema proposto foi criada uma entidade que se responsabiliza pelocarregamento dinâmico dos módulos do formatador e a extração de tais módulosdo fluxo MPEG-2: o GingaXletDeployer.5.2.2.O Módulo de ImplantaçãoEsse módulo é responsável por realizar a implantação do ambientedeclarativo. A implementação desse módulo vai depender da plataforma para aqual o ambiente declarativo se destina. Pode oferecer, inclusive, mecanismossofisticados de implantação/monitoramento dos componentes. No entanto, nocaso de sistemas GEM sua implementação deve ser simplificada.Para a implementação desse componente foram criadas quatro classes:GingaXlet, IGingaXletConfiguration, IGingaXletDeployer eStreamEventHandler.Figura 29 – Classe GingaXlet.A classe GingaXlet, mostrada na Figura 29, é a implementação da interfaceXlet necessária para o modelo de programação do Java TV. Essa classe é o pontode entrada da aplicação e, através dela, o Gerenciador de Aplicações do receptorcontrolará o ciclo de vida da aplicação. A assinatura dessa classe é idêntica a deum Xlet mostrada na Figura 9 na Seção 2.4. A classe GingaXlet possui referênciapara todos os componentes instanciados no sistema e para a entidadeStreamEventHandler, que será apresentada a seguir. A utilidade desses atributosserá apresentada na Seção 5.2.3.

O Fomatador NCL Xlet 74Figura 30 – Classe IGingaXletConfiguration.A classe que implementa a interface IGingaXletConfiguration, mostrada naFigura 30, guarda parâmetros de configuração para a execução da aplicação.Através dela a aplicação pode acessar parâmetros provenientes do Gerenciador deAplicações, fornecidos na inicialização da aplicação via sinalização ou presentesem arquivos de configuração. Existem dois parâmetros importantes fixados pelaIGingaXletConfiguration, são eles: a localização das bibliotecas disponíveis, ouseja, o diretório no qual os componentes e demais bibliotecas estarão disponíveis;e a localização do objeto de eventos a partir do qual serão enviados os comandode edição NCL.A instanciação dessa classe ocorre no momento de iniciação (chamada aométodo “initXlet”) do Xlet. Isso porque essa classe deve acessar o contexto doXlet para ter acesso às suas propriedades.Figura 31 – Interface IGingaXletDeployer.A classe que implementa a interface IGingaXletDeployer, mostrada naFigura 31, é responsável pela implantação do Formatador. O processo todo érealizado quando chamado o método deployFormatter. Esse método esconde todaa lógica de localização dos componentes (que podem apresentar-se no fluxoMPEG-2, no sistema de arquivos local ou serem obtidos via canal de retorno),quais componentes serão carregados e a conexão entre tais componentes. Maisdetalhes sobre o funcionamento desse método são fornecidos na Seção 5.3. Emcontrapartida, seu método undeployFormatter é responsável por realizar a

O Fomatador NCL Xlet 75finalização dos componentes permitindo, caso o ambiente permita, oarmazenamento destes para futuro reuso.A classe possibilita, ainda:• O carregamento de classes a partir da URL de uma biblioteca Java;• A pré-busca (prefetch) de classes a partir da URL de uma bibliotecaJAVA;• O carregamento de arquivos a partir de uma URL de localização doarquivo;• E o pré-carregamento de arquivos a partir de uma URL delocalização do arquivo.A classe StreamEventHandler é responsável por tratar os eventos DSM-CCenviados no fluxo MPEG-2. Sua assinatura, mostrada na Figura 32, é herdada dainterface org.dvb.dsmcc.StreamEventListener descrita naespecificação do MHP.Figura 32 – A classe StreamEventHandler e suas associações.A implementação do método receiveStreamEvent dessa classe determinará,por exemplo, o tratamento apropriado para os comandos de edição. Essetratamento envolve o envio dos Comandos de Edição NCL para o componenteGerenciador de Documentos ou a alteração do estado da apresentação doFormatador. Dessa forma, essa classe possuirá uma referência para o ComponenteGerenciador de Documentos e o Componente do Núcleo do Formatador.Para exercer suas funções, essa classe deverá se cadastrar, para notificação,em um objeto de eventos (Stream Event Object) específico do Carrossel deObjetos. Esse objeto de eventos é obtido através da interfaceIGingaXletConfiguration. Ao se cadastrar nesse objeto, a classe será notificada àmedida que os eventos DSM-CC aparecerem no fluxo MPEG-2.

O Fomatador NCL Xlet 765.2.3.O Processo de Implantação do FormatadorA seguir será descrito o processo de implantação do formatador partindo do produtorde conteúdo.5.2.3.1.O ProdutorO produtor de conteúdo será responsável por enviar os componentes e osdocumentos para a apresentação. Para isso, o produtor deverá sinalizar, via AIT, alocalização no Carrossel DSM-CCdocumentos e mídias envolvidas na apresentação.dos componentes de software e dosCaso seja adotada a estratégia de pré-conversão do documento NCLprodutor deverá instanciar o Componente Gerenciador de Documentos, adicionaros documentos necessários para a apresentação e adicionar este novo objeto Javaserializado no mesmo diretório onde se localizarão os componentes.5.2.3.2.O ReceptorO processo de implantação do Formatador Xlet inicia-se quando suapresença é sinalizada para o receptor (por exemplo, através da AIT). Nessa fase épassada como parâmetro para a aplicação, obrigatoriamente, a localização dosexibidores e do Stream Event Object através do qual serão recebidos os eventosde edição.Depois de recebida a sinalização, o Gerenciador de Aplicações assume ocontrole do Formatador com a instanciação da classe GingaXlet. O gerenciador,então, inicia o ciclo de vida do GingaXlet com a chamada ao seu método initXlet,herdado da interface Xlet do Java TV.No processo de preparação da classe GingaXlet, ilustrado na Figura 33, serárealizada a configuração do ambiente através da classe GingaXletConfiguration(classe que implementa a interface IGingaXletXonfiguration). A essa classe épassado o Contexto de execução do Xlet de onde é obtida parte dos parâmetros deconfiguração utilizados pela aplicação, dentre eles os argumentos passados para a

O Fomatador NCL Xlet 77aplicação (como o Localizador das bibliotecas e o Localizador do objeto deeventos que conterá os eventos para a identificação de recursos exposta na Seção4.3 e demais eventos de edição NCL).Após a criação da entidade de configuração, é instanciada a entidade deimplantação do Formatador denominada GingaDeployer (classe que implementa ainterface IGingaXletDeployer). Essa entidade, como já mencionado, estádiretamente ligada à versão do Formatador a ser implantada. Ela fará ocarregamento de cada componente realizando sua instanciação e resolvendo suasdependências.Feita a implantação do Formatador, o GingaDeployer passará o controledesta entidade ao GingaXlet. Assim, qualquer alteração no estado da aplicação(Xlet) poderá ser refletido no estado da apresentação do Formatador viaGingaXlet, ou seja, no momento em que os métodos pauseXlet ou destroyXletdessa classe forem chamados, a execução do Formatador será interrompida.Figura 33 – Diagrama de seqüência do processo de preparação do Formatador Xlet.Ainda no método de iniciação do Xlet será criado o StreamEventHandler. Aessa classe serão passadas as referências para o Componente Gerenciador deDocumentos e o Componente do Núcleo do Formatador.No método startXlet da classe GingaXlet, seu atributo que contém areferência para o StreamEventHandler se cadastrará em um objeto de eventosDSM-CC (fornecido pelo IGingaXletConfiguration). Esse objeto é representadopela classe DSMCCStreamEvent do MHP. Após o cadastro, o

O Fomatador NCL Xlet 78StreamEventhandler receberá os comandos de edição e repassará para osComponentes do Núcleo do Formatador e Gerenciador de Documentos,permitindo o início da apresentação. Esse processo é mostrado na Figura 34.Figura 34 – Diagrama de seqüência do processo de inicialização do Formatador Xlet.No método pauseXlet a apresentação do Formatador é parada (e não apenaspausada) e o StreamEventHandler é descadastrado do objeto de Eventos DSM-CCdeixando de receber os comandos de edição.No método destroyXlet ocorre o mesmo procedimento do método pauseXlet, noentanto, é o método undeployFormatter da classe GingaXletDeployer é chamado parafinalizar os componentes.5.2.4.Persistência do Formatador NCL Xlet em Receptores MHPA implementação do Formatador NCL para sistemas GEM proposta nessetrabalho se adapta facilmente tanto ao mecanismo de plug-ins como aoarmazenamento de aplicações, mostrados no Capítulo 3, sem grandesmodificações.No caso do mecanismo de plug-ins, a implementação da interfaceorg.dvb.application.plugins.Plugin torna-se trivial, sendo necessárioapenas instanciar a implementação da classe GingaXlet e retorná-la no métodoinitApplication. Dessa forma, o sistema agirá, na presença de um documentoNCL, como se possuísse nativamente a capacidade de interpretá-lo.No caso da utilização do mecanismo de Application Storage, são grandes asvantagens apresentadas. Nenhum esforço precisa ser feito em termos deimplementação. A diferença das aplicações que utilizam esse mecanismo estáapenas no processo de sinalização.

O Fomatador NCL Xlet 79Um fator restritivo na utilização desses dois mecanismos é que eles devemser utilizados isoladamente em uma rede de comunicação, ou seja, naapresentação de um programa deverá ser utilizado apenas um dos tipos desinalização possíveis para a execução do Formatador NCL: o convencional quetrata o Formatador como um aplicação Java; a sinalização de um documentoNCL como uma aplicação a ser executada pelo plug-in; ou a sinalização paraexecução de uma aplicação armazenada.5.3.TestesPara a validação do sistema criado nesta dissertação foi criado um ambientede testes utilizando a configuração de máquina virtual CDC (SUN, 2005b)oferecida pela SUN juntamente com o perfil PBP. Foi utilizada, ainda, umaimplementação do middleware MHP aberta conhecida como OpenMHP (Tucs &Axel, 2005). Nesse middleware foram realizadas adaptações de forma a melhorrefletir um ambiente de TV Digital. A plataforma escolhida foi um sistema Linuxinstalado sobre uma arquitetura x86.O sistema implantado no teste é mostrado na Figura 35. Ele é composto por:• Um Núcleo do Formatador com suporte à edição ao vivo;• Um Gerenciador de Leiaute customizado para TV;• Um Gerenciador de Documentos customizado para TV;• Um Gerenciador de Exibidores customizado para TV;• Um componente exibidor de Texto customizado para TV; e• Um componente exibidor de Imagem customizado para TV.

O Fomatador NCL Xlet 80Figura 35 – Digrama de componentes do Sistema testado.O tamanho final dos componentes implementados é mostrado na Tabela 1,sendo que:• O arquivo “Deployer.jar” corresponde ao componente deimplantação;• O arquivo “Compile.jar” corresponde ao Gerenciador deDocumentos;• O arquivo “Ginga.jar” corresponde ao Núcleo do Formatador,Gerenciador de exibidores e Gerenciador de Leiaute somados;• O arquivo “ImagePlayerAdapter.jar” corresponde ao componente doexibidor de imagens estáticas; e• O arquivo “TextPlayerAdapter.jar” corresponde ao componetneexibidor de texto.ComponenteDeployer.jarCompiler.jarGinga.JarDiserializer.JarImagePlayerAdapterTextPlayerAdapterTamanho6,5 KB111 KB148 KB1,5 KB4,4 KB4,3 KBTotal275,7 KBTabela 1 – Componentes do formatador GingaXletA fim de verificar a viabilidade da serialização do componente Gerenciadorde Documentos, foram realizados testes de desempenho comparando dois

O Fomatador NCL Xlet 81cenários: serialização contra a conversão do documento XML. Na serialização otempo foi medido desde a leitura do objeto serializado (que foi pré-convertido) atéa presença de sua instância. Na conversão o tempo foi medido entre a leitura dodocumento XML até a presença da instância do Gerenciador de Documentosjuntamente com o documento convertido. Os arquivos testados fazem parte de umconjunto de documentos elaborados pelo Laboratório de Telemídia da Puc-Riopara o teste de conformidade do Ginga-NCL. Para cada arquivo testado foramrealizados 1000 ensaios. Nos testes, os documentos a serem executados foramadicionados ao Gerenciador de Documentos e este foi serializado. Aimplementação utilizada da interface IGingaXletDeployer realiza a implantaçãodo Formatador através da desserialização do componente Gerenciador deDocumentos e instanciação dos demais componentes do sistema.Serialização(ms)Conversão(ms)Documentos Mínimo Máximo Médio Mínimo Máximo MédioconnectorBase.ncl 10 15 11 25 29 26descriptor01.ncl 26 60 31 47 54 49descriptor02.ncl 27 134 33 49 54 50descriptor03.ncl 33 60 38 55 67 57descriptor04.ncl 33 96 39 56 152 59descriptor05.ncl 27 49 30 49 54 50descriptor06.ncl 26 42 28 47 53 49descriptor07.ncl 30 38 32 53 61 55descriptor08.ncl 33 61 35 56 156 59descriptor09.ncl 27 33 28 49 55 50descriptor10.ncl 27 34 28 49 56 51descriptor11.ncl 27 33 28 49 56 50descriptor12.ncl 26 43 28 49 55 50Structure01.ncl 9 21 10 11 14 12Structure02.ncl 9 19 10 11 14 12Structure03.ncl 9 19 10 11 18 12Structure04.ncl 9 18 10 12 63 13Structure05.ncl 9 14 10 11 19 12Tabela 2 – Resultados dos testes de Serialização versus conversãoOs resultados obtidos pelos testes são mostrados naSerialização(ms)Conversão(ms)Documentos Mínimo Máximo Médio Mínimo Máximo MédioconnectorBase.ncl 10 15 11 25 29 26descriptor01.ncl 26 60 31 47 54 49descriptor02.ncl 27 134 33 49 54 50descriptor03.ncl 33 60 38 55 67 57descriptor04.ncl 33 96 39 56 152 59descriptor05.ncl 27 49 30 49 54 50descriptor06.ncl 26 42 28 47 53 49descriptor07.ncl 30 38 32 53 61 55descriptor08.ncl 33 61 35 56 156 59

O Fomatador NCL Xlet 82descriptor09.ncl 27 33 28 49 55 50descriptor10.ncl 27 34 28 49 56 51descriptor11.ncl 27 33 28 49 56 50descriptor12.ncl 26 43 28 49 55 50Structure01.ncl 9 21 10 11 14 12Structure02.ncl 9 19 10 11 14 12Structure03.ncl 9 19 10 11 18 12Structure04.ncl 9 18 10 12 63 13Structure05.ncl 9 14 10 11 19 12Tabela 2. Pode-se perceber que: em todos os testes o cenário utilizando aserialização é, em média, ligeiramente inferior, em se tratando de tempo deespera; e que os testes não mostraram nenhum indício de que tal cenário nãopossa ser adotado.Outro teste a ser realizado consiste em verificar o tamanho do arquivo NCLserializado em comparação com o arquivo em sua forma convencional e se oretardo provocado por essa diferença é definitivamente relevante. No entanto esseteste será alvo de trabalhos futuros.

6ConclusõesO objetivo principal deste trabalho foi elaborar um ambiente de execuçãodeclarativo para sistemas que implementem a especificação do GEM. O ambientedesenvolvido foi baseado na implementação Java do Formatador NCL criada peloLaboraório TeleMídia da PUC-Rio e permite que os programas declarativosproduzidos para o Sistema Brasileiro de TV Digital Terrestre sejam apresentadosem qualquer sistema que implemente o framework GEM.A fim de melhor compreender as tecnologias envolvidas na elaboraçãodesse ambiente, foram apresentados no Capítulo 2 os middleware para TV DigitalTerrestre que implementam a especificação do GEM e foi feita uma brevedescrição deste padrão.No Capítulo 3, foram descritos alguns trabalhos relacionados com o temaproposto nesta dissertação. Foram analisadas duas implementações de ambientesdeclarativos para sistemas GEM tendo como base a linguagem SMIL. A partir dostrabalhos realizados na linguagem SMIL, foi possível compreender a grandedificuldade encontrada no desenvolvimento de aplicações para sistemas de TVDigital: o tempo de iniciação. Ou seja, o tempo decorrido desde a recepção dodocumento declarativo até sua exibição.Ao final do Capítulo 3, foi apresentada a implementação Java doFormatador NCL, que serviu como base para o ambiente proposto nestadissertação. Essa implementação foi alterada visando atender à API diferenciadado GEM e aos requisitos inerentes a sistemas de TV Digital (como, por exemplo,o tempo de iniciação) Seus módulos foram transformados em componentes desoftware, sendo criadas diferentes implementações desses componentes,atendendo tanto a desktops como sistemas GEM.Foi desenvolvida uma estratégia diferente de implantação do FormatadorNCL para receptores com recursos de memória limitados. Essa estratégia faz usodo mecanismo de serialização, oferecido pela linguagem Java, e realiza todo oprocesso de conversão do documento NCL em seu distribuidor.

Conclusões 84Outra otimização (mostrada no Capítulo 4) pode ser realizada para sistemasDVB-MHP que ofereçam suporte às facilidades de plug-ins interoperáveis earmazenamento de aplicações. Dessa forma, o ambiente declarativo propostopoderá se comportar como aplicação nativa nos receptores.As otimizações propostas levem a uma implantação enxuta do Formatador,permitindo uma redução do seu tamanho e tornando-o, inclusive, menor que oexibidor SMIL apresentado no Capítulo 3. Em sistemas com suporte àpersistência de dados e de mídia empacotada (como o Blue-Ray Disc) asotimizações permitem um desempenho ainda maior em termos de tempo deiniciação.6.1.Trabalhos FuturosAlguns pontos dos trabalhos realizados nesta dissertação podem serexplorados como trabalhos futuros.A configuração de máquina virtual CDC e seus perfis possuemimplementações disponíveis para as mais diversas plataformas (mostradas naTabela 3). Novos testes em novas plataformas são valiosos para a validação daimplementação proposta nesta dissertação.Darwin/PowerPCLinux/ARMLinux/MIPSLinux/PowerPCLinux/SparcLinux/x86Solaris/SparcSolaris/x86Symbian/ARMSymbian/x86Vxworks/SparcVxworks/x86Win32/ARM/PocketPCWin32/ARM/WindowsMobile5Win32/MIPS/WindowsCEWin32/x86Win32/x86/PocketPCTabela 3 – Plataformas que implementam o CDC.

Conclusões 85Outro aspecto mostrado neste trabalho que pode render trabalhos futuros é amodelagem do Formatador NCL baseada em componentes. Nem todas asfacilidades proporcionadas por essa modelagem puderam ser aproveitadas nestetrabalho por motivos de requisitos do sistema (como mostrado na Seção 4.3.1).Em ambientes que ofereçam suporte a diferentes linguagens de programação, porexemplo, pode haver uma cooperação entre componentes implementados nessasdiferentes linguagens.Figura 36 – Arquitetura de execução distribuída do Formatador NCL.Além disso, pode-se explorar a distribuição desses componentes criandoarquiteturas de execução como a mostrada na Figura 36. Nessa Figura, existe umcomponente Gerenciador de Documentos centralizado de onde vários Núcleos deFormatadores obtêm os documentos NCL a serem apresentados.Utilizando esse mesmo componente podem existir, ainda, diversasferramentas de autoria. Dessa forma seria possibilitada uma autoria colaborativade documentos NCL ao vivo.

7Referências BibliográficasARIB. ARIB STD-B24, Version 3.2, Volume 3: Data Coding and TransmissionSpecification for Digital Broadcasting, ARIB Standard, 2002.ARIB. ARIB STD-B23, Application Execution Engine Platform for DigitalBroadcasting. ARIB Standard, 2004.ATSC. DTV Application Software Environment Level 1 (DASE-1) PART 1:Introduction, Architecture, and Common Facilities. ATSC Standard. Marçode 2003.ATSC. DTV Application Software Environment Level 1 (DASE-1) PART 2:Declarative Applications and Environment. ATSC Standard, Março de 2003.ATSC. Advanced Common Application Platform (ACAP), A/101. Agosto de2005.BDA, Blue-Ray Disc Format – 2.B Audio Visual Application FormatSpecifications for BD-ROM. White paper. Março de 2005.BERNERS-LEE, T. J. The World-Wide Web. Communications of the ACM, v.37, n. 8, Agosto de 1994, p. 76-82.BULTEMAN, D.; RUTLEDGE, L. SMIL 2.0: Interactive Multimedia for Weband Mobile Devices, Springer, 2004.BROWN, A. W.; WALLNAU, C. K. International Workshop on Component-Based Software Engineering. International Conference on SoftwareEngineering ’99 – Los Angeles. 1999.ECMA Standardizing Information and Communication Systems. ECMAScriptLanguage Specification, Standard ECMA 262, 3rd Edition, 1999.ETSI. Digital Video Broadcasting (DVB), Globally Executable MHP (GEM),ETSI TS 102 819 v 1.2.1, Maio de 2004.ETSI. Digital Video Broadcasting (DVB), Multimedia Home Platform (MHP)

Referências Bibliográficas 87Specification 1.1.1, ETSI TS 102 812, Maio de 2005. Disponível em:. Acesso em 12/03/2007.FERRETTI, S.; ROCCETTI, M.; ANDRICH, J. Living the TV Revolution:Unite MHP to the Web or Face IDTV Irrelevance! 15th InternationalConference on World Wide Web, p.899-900, 2006.FUHRHOP, C.; HU, J.; GAFSOU, O. Prototype of Applications, User Interfacesand End User Tools, IST-2000-28298: ICE-CREAM. Abril de 2003.GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J., Padrões de Projeto,Editora Bookman, Porto Alegre, 2002.GEARY, D. M., MCCLELLAN, A. L. Graphic Java: mastering the AWT.SunSoft, Prentice Hall, 1997.GOSLING, J.; MCGILTON H. The Java Language Environment. Maio de1996. Disponível em: . Acesso em15/01/2007.FILHO, G. L. S. F.;LEITE, L. E. C.; BATISTA, C. E. C. F. Ginga-J: TheProcedural Middleware for the Brazilian Digital TV System. Journal of TheBraziian Computer Society, Março de 2007, p. 47-56.HAVi Organization, HAVi-Home Audio/Video Interoperability. 1999,Disponível em: . Acesso em 20/10/2005.IERUSALIMSCHY et al. Lua 5.0 Reference Manual. Technical Report MCC -14/03, PUC-Rio, 2003.ISO/IEC 11172-1. Information technology - Coding of moving pictures andassociated audio for digital storage media at up to about 1,5 Mbit/s –Part 1: Systems. ISO Standard, 1993.ISO/IEC 13522-5. Information technology - Coding of multimedia andhypermedia information -- Part 5: Support for base-level interactiveapplications. ISO Standard, 1997.ISO/IEC 13818-6. Information technology - Generic coding of movingpictures and associated audio information - Part 6: Extensions for DSM-CC. ISO Standard, 1998.

Referências Bibliográficas 88ITU-T. Worldwide common core – Application environment for digitalinteractive television services. ITU-T J.200. Março de 2001.ITU-T. Harmonization of procedural content formats for interactive TVapplications. ITU-T J.202. Maio de 2003.ITU-T. Harmonization of declarative content format for interactive televisionapplications. ITU-T J.201. Julho de 2004.LAMANDON, J. L.; CESAR, P.; HERRERO, C.; VUORIMAA, P. “Usages of aSMIL Player in Digital TV” VII IASTED International Conference onInternet and Multimedia Systems and Applications, Agosto de 2003, p. 579-584.LARMAN, C., Utilizando UML e Padrões – Uma Introdução à análise e aoProjeto Orientados a Objetos. Editora Bookman, 2002.LIANG, S.; BRACHA, G. Dynamic Class Loading in the Java VirtualMachine. Conference on Object-oriented programming, systems, languages,and applications (OOPSLA'98), Vancouver, Canadá, Outubro de 1998.MHP, Who is using MHP? A look around the world. Setembro de 2006.Disponível em: .Acesso em: 14/01/2007.OPENCABLE, Opencable Application Plataform Specification - OCAP 1.0Profile – OC-SP-OCAP1.0-I16-050803. Issued Specification, Agosto de2005.PENG, C.; VUORIMAA, P. Digital Television Application Manager. IEEEInternational Conference on Multimedia and Expo 2001, Tóquio, Japão,Agosto de 2001.PERROT, . DVB-HTML: an optional declarative language within MHP 1.1.EBU Technical Review. Setembro de 2001.RFC. Request for Comments: 3986. Uniform Resource Identifier (URI):Generic Syntax. 2005.ROBINSON, M; VOROBIEV, P. Swing. 2ed. Manning, 2003.

Referências Bibliográficas 89RODRIGUES, R.F., Formatação e Controle de Apresentações Hipermídiacom Mecanismos de Adaptação Temporal. Tese (Doutorado emInformática) – PUC-RJ, Rio de Janeiro 2003.SCHEIFLER, R. W.;GETTYS, J. X Window System: Core and extensionprotocols: X version 11, releases 6 and 6.1. Digital Press, 1996.SCHWALB E. M. iTV Handbook - Technologies and Standards, IMSC PressMultimedia Series, Prentice Hall PTR, 2004.SHEPPARD, Bill; MOLL, E. Java Technology Goes to the Movies: JavaTechnology in Next-Generation Optical Disc Formats. 2006 JavaOneConference, Session TS-1685, Maio de 2006.SZYPERSKI, C. Component Software. 2ed. Addison-Wesley, 2002, 446p.SOARES, L.F.G.; RODRIGUES, R.F.; MUCHALUAT-SAADE, D.C. Modelode Contexto Aninhados – versão 3.0. Relatório Técnico, LaboratórioTelemídia PUC-Rio, Março de 2003.SOARES, L.F.G.; RODRIGUES, R.F. Nested Context Language 3.0 Part 8 –NCL Digital TV Profiles. Monografias em Ciências da Computação, PUC-Rio, Outubro de 2006.SOARES, L.F.G. et al, Nested Context Language 3.0 Part 9 – NCL LiveEditing Commands. Monografias em Ciências da Computação, PUC-Rio,Dezembro de 2006.SOARES, L.F.G.; RODRIGUES, R.F.; Mecanismo de Identificação deRecursos para Aplicações Interativas em Redes de TV Digital porDifusão. 25 o Simpósio Brasileiro de Redes de Computadores e SistemasDistribuídos. Maio de 2007.SUN MICROSYSTEMS. Applets. 1994. Disponível em:. Acessado em: 15/01/2007.SUN MICROSYSTEMS. Java Media Framework, v2.0 API Specification.1999. Disponível em: .Acessado em: 15/01/2007.

Referências Bibliográficas 90SUN MICROSYSTEMS. Object Serialization. 1999. Disponível em:. Acessado em:17/05/2007.SUN MICROSYSTEMS. Permissions int the Java 2 SDK. 2002. Disponívelem: .Acessado em: 17/01/2007.SUN MICROSYSTEMS. CDC: Java Plataform Technology for ConnectedDevices. Java Plataform Micro Edition White Paper. Junho de 2005.SUN MICROSYSTEMS. CDC Runtime Guide. Reference Implementation.Agosto de 2005.TUCS; AXEL Technologies. OpenMHP: Multimedia Home Plataform. 2004.Disponível em: . Acessado em: 15/01/2007.W3C. Cascading Style Sheets, level 2 - CSS 2 Specification, W3CRecommendation, 1998.W3C. HTML 4.01 Specification. W3C Recommendation, Dezembro de 1999.W3C. XHTML 1.0 The Extensible HyperText Markup Language (SecondEdition) – A Reformulation of HTML 4 in XML 1.0. W3CRecommendation, Agosto de 2002.W3C. Document Object Model (DOM) Level 3 Core Specification. W3CRecommendation, Abril 2004.W3C. XML Schema Part 0: Primer Second Edition. W3C Recommendation,Outubro de 2004.W3C. Synchronized Multimedia Integration Language (SMIL 2.1). W3CRecommendation, Dezembro de 2005.WEBER, J. W.; NEWBERRY, T. IPTV Crash Course. McGraw-Hill, 2006.

Apêndice AAssinatura Digital de um XletA execução de aplicações em receptores de TV digital domésticos permite oacesso a recursos em tais equipamentos que, no caso de um comprometimento desua segurança, podem expor dados sigilosos de seus usuários. Para restringir oacesso a tais recursos sensíveis do receptor, foram criados mecanismos quepermitissem a sua utilização por aplicações confiáveis.O uso dos Arquivos de Requisição de Permissão (PRFs) é um mecanismocriado para permitir o acesso pelas aplicações a certos recursos sensíveis dosreceptores em termos de falhas de segurança. Esses recursos incluem, porexemplo, acesso ao disco local, às preferências dos usuários, ao uso do canal deretorno, entre outros. Vale lembrar que o acesso a tais ativos deve ser controladodevido ao fato de as aplicações não necessariamente localizarem-se apenas nofluxo de transporte proveniente das difusoras; elas podem ser obtidas também viacanal de retorno por provedores de conteúdo das mais diversas origens.A especificação do GEM prevê que um receptor que suporte tal frameworkseja capaz, no mínimo, de processar os PRFs criados pelo padrão MHP. A Figura37 ilustra um exemplo de arquivo e configuração que respeita tal padrão. Oarquivo do exemplo permite a leitura das preferências do usuário; o uso do canalde retorno; bloqueia a sintonização; permite a seleção do serviço; permite a leiturae escrita de dois arquivos; entre outros.+552135211500+552135211501

Apêndice AAssinatura Digital de um Xlet 92hostname23d2/4020/formatterConfig/context/context.ini23d2/4020/formatterConfig/players/mimedefs.ini23d2/4020/formatterConfig/players/ctrldefs.ini 0232032932929329329214931439294239432942394323Figura 37 – Exemplo de arquivo PRF.O arquivo PRF permite ainda a leitura de três arquivos localizados nodispositivo de armazenamento local no receptor: context.ini, mimedefs.ini ectlrdefs.ini.Os dois diretórios iniciais do caminho de acesso a tais arquivos consistemdo identificador da organização e o identificador da aplicação responsáveis porrealizar sua gravação em disco. Isso é parte de uma padronização proposta peloMHP e absorvida pelo GEM que permite a uma aplicação criar arquivos apenasem diretórios que contenham em seu caminho inicialmente tais identificadores.Vale ressaltar que é permitido que diferentes organizações/aplicaçõesacessem um arquivo gravado em disco. Contudo, é necessário apresentar noarquivo PRF o identificador da organização responsável pela gravação original doarquivo (através do elemento “grantoridentifier”) e uma assinatura (através doelemento “signature”). Com isso, o receptor terá garantias que esta novaaplicação tem permissão de ler/alterar um arquivo que não foi originalmente porela criado.

Apêndice AAssinatura Digital de um Xlet 93Figura 38 – Estrutura de diretórios de um Xlet.Uma aplicação corretamente certificada possui uma estrutura semelhante àmostrada na Figura 38:• O PRF localiza-se no mesmo diretório da classe inicial (que noexemplo é TestXlet.class e o arquivo PRF é isdtv.TestXlet.perm); e• Todos os diretórios que tiverem seu conteúdo assinado possuirãoum arquivo contendo uma assinatura do tipo hash de todo ele(utilizando o algoritmo MD5, por exemplo). No exemplo da Figura38, o diretório “data” não tem seu conteúdo assinado.

Apêndice BSinalização de AplicaçõesO processo de sinalização de aplicações recomendado pelo GEM eadotado pelo MHP envolve o envio periódico de uma tabela denominada Tabelade Informação de Aplicações (AIT – Application Information Table). Essastabelas constituem um fluxo elementar do fluxo de transporte MPEG-2. Elas sãoum tipo de PSI (Program Specific Information). Esse apêndice explica osprincipais atributos presentes na AIT e relevantes para a implementação de umaaplicação DVB-J.As AITs são identificadas na PMT como um fluxo do tipo 0x05. Alémdisso, opcionalmente, a PMT pode conter um descritor de sinalização contendo otipo de aplicação e a versão da AIT. Dessa forma, o processo de sinalização ficaotimizado pois, receptores que não possuam capacidade de processar umdeterminado tipo de aplicação não necessitam decodificar toda a AIT, e mudançasna AIT são mais facilmente detectadas através do indicador de versão.Cada tabela AIT possui, principalmente, zero ou mais descritores comuns,contendo informações compartilhadas por todas as aplicações nela descritas, umalista com os descritores de informações específicas de cada uma dessasaplicações, além dos campos tipo da aplicação, os códigos de controle daaplicação, os identificadores das aplicações e a versão da tabela.O campo “tipo de aplicação” leva o número 0x0001 para aplicaçõesDVB-J.O campo “versão da tabela” funciona como uma otimização para queuma atualização em seu conteúdo possa ser mais facilmente detectada.O “código de controle” serve para controlar o ciclo de vida a aplicação. Oque significa dizer que através dele a emissora pode mandar comandos paraencerrar uma aplicação, auto iniciar ou apenas informar a sua disponibilidade parao usuário.Os “identificadores das aplicações” são um par contendo o identificadorda organização que produziu a aplicação e o identificado da aplicação.

Apêndice BSinalização de Aplicações 95A Tabela 4 mostra os principais campos, citados anteriormente, e seusrespectivos valores a fim de exemplificar uma AIT para o carregamento doFormatador NCL.Tipo de Aplicação0x0001 (DVB-J)Versão0x0Descritores comuns()for(i=0;i

Apêndice BSinalização de Aplicações 96cada aplicação não podendo ser declarados juntamente com osdescritores comuns;• Os descritores específicos de aplicações DVB-J que informam: osparâmetros para a aplicação; o diretório base que representa ocaminho (path) para execução da aplicação; caminhos adicionaispara classes a serem inicializadas junto com a aplicação (classpathextensions); a classe inicial da aplicação.Perfil da aplicação0x1(Enhanced Profile)Version.Major0x1Version.Minor0x1Version. Micro0x1Protocolo de transporte(){0x0001Identificador rede original0x12Identificador fl. De transporte 0x1Identificador serviço0x12}ISO_639_language_codept-brNome da aplicaçãoGinga-NCLDiretório base/app/Extensão ao classpath/playersClasse inicialGingaXletTabela 5 – Parâmetros adicionais da AIT para sinalização do Formatador Xlet.No caso da utilização das facilidades proporcionadas pelos plug-ins doDVB-MHP ou Application Storage (Armazenamento de Aplicações), mais algunsdescritores spodem ser utilizados:• Um descritor para delegação de aplicação. Esse descritor pode sercomum ou específico de uma aplicação e nele é especificado oidentificador da aplicação responsável por interpretar aqueleconteúdo;• Um descritor de plug-ins que informa qual tipo de aplicação oplug-in é capaz de interpretar. Esse descritor deve ser informadopara cada plug-in presente na lista de aplicações;

Apêndice BSinalização de Aplicações 97• Um descritor de aplicações armazenadas. Nesse descritor éinformado, principalmente, se o ciclo de vida da aplicação écontrolado pela difusora ou requer a interação do usuário (comojogos, por exemplo), e a versão da aplicação.

Apêndice CA Linguagem NCLPara a construção de aplicações interativas para sistemas de TV Digital fazsenecessário o sincronismo entre as mídias envolvidas neste sistema. Além dosincronismo do vídeo e áudio principal, o sistema de TV Digital deve ser capaz delidar com a sincronização espacial e temporal de objetos de diferentes tipos demídia.O XHTML, usado pela maioria dos middlewares descritos neste capítulo, éuma linguagem baseada em um modelo hipermídia bastante simples. Apesar desua simplicidade ser um dos fatores que contribuiu para a sua grande difusão, estaintroduz limitações como, por exemplo, o fato de permitir apenas o sincronismoespacial. Para se obter sincronismos espaço-temporais é necessário recorrer arecursos fora do paradigma declarativo, como o uso do ECMAScript.O modelo hipermídia no qual foi baseado o XHTML define apenasentidades do tipo nó e elo, sendo que existe apenas um tipo de elo (usado pararepresentar relações de referência), diminuindo, assim, o poder de expressão dalinguagem. Esse modelo limitado determina, ainda, que a definição dos elos estejacontida no nó, tornando impossível reusar um documento sem herdar os elosdefinidos dentro dele.O W3C, órgão oficial que regula os padrões da World Wide Web, define oSMIL (W3C, 2005) como linguagem oficial para o sincronismo de mídias. Nessalinguagem, solucionando o problema do HTML, os elos não se encontramdefinidos dentro dos nós. É especificada nela, ainda, uma entidade denominadaComposição. A Composição contém um conjunto de elos e nós e, no caso doSMIL, estabelece uma semântica de sincronização. As Composições podem ser detrês tipos: paralela, seqüencial ou exclusiva. A atribuição dessa semântica àsComposições, no entanto, pode dificultar o processo de autoria quando na criaçãode relacionamentos complexos. Outro fator limitante dessa linguagem é fato delanão oferecer suporte à edição/geração ao vivo de documentos.

Apêndice CA Linguagem NCL 99A NCL (Nested Context Language) é uma linguagem XML para a autoriade apresentações hipermídia, incluindo programas de TV não lineares, baseada nomodelo hipermídia NCM (Nested Context Model) (Soares et al, 2003). Seu foco éo sincronismo de mídias.Por ser baseada no modelo NCM, a linguagem permite:• o uso de composições para a estruturação lógica do documento;• o uso de conectores hipermídia para a autoria de elos e fornecendo asemântica de sincronismo destes;• a possibilidade de escolha entre um conjunto de nós alternativos; e• a especificação da apresentação por meio de descritores.A NCL define como os objetos de mídia estão estruturados e como serelacionam, no tempo e no espaço. Contudo, ao contrário do SMIL, os tipos deconteúdo desses objetos de mídia não são restritos. Ou seja, num documento NCLos objetos de mídia além de consistir de imagens estáticas, áudio, vídeo e texto,amplamente implementado pelas demais linguagens, podem representar objetosde execução (programas na linguagem Lua, JAVA,etc.) ou até documentos deoutras linguagens (XHTML, SMIL,etc.). Por esse motivo a linguagem NCL éconhecida como uma linguagem de cola.Outra vantagem da linguagem NCL é que esta permite a autoria dedocumentos em tempo de apresentação, ou seja, ela permite a alteraçãodocumento durante a sua execução. Esta funcionalidade é de grande valor emsistemas de TV digital onde a transmissão de programas ao vivo, como eventosesportivos, requerer uma alteração em tempo real da apresentação. Nesseambiente, a autoria em tempo de apresentação é realizada através do envio decomandos de edição via NCL stream events (eventos DSM-CC).A versão atual do NCL encontra-se especificada usando XML Schema(W3C, 2004b). Nela é prevista a existência de dois perfis: um Perfil Básico e umPerfil Avançado para TV digital. Esses perfis podem ser construídos graças àcaracterística modular da linguagem através da seleção de módulos específicos.Estes módulos que compõem a linguagem são um conjunto de elementos,atributos e valores de atributos XML que representam uma unidade funcional.As áreas funcionais da linguagem e seus respectivos módulos são os queseguem:Estrutural – módulo Structure;

Apêndice CA Linguagem NCL 100Leiaute – módulo Layout;Componentes – módulo Media e módulo Context; Interfaces – módulo MediaContentAnchor, móduloCompositeNodeInterface, módulo AttributeAnchor, e móduloSwitchInterface;Especificação da Apresentação – módulo Descriptor;Elos – módulo Linking;Conectores – módulo XConnector e módulo CompositeConnector;Controle da Apresentação – módulo TestRule, módulo TestRuleUse,módulo ContentControl e módulo DescriptorControl;Temporização – módulo Timing; Reuso – módulo Import, módulo EntityReuse e móduloExtendedEntityReuse;

Apêndice CA Linguagem NCL 101Figura 39 – Exemplo de documento NCL 2.0A Figura 38 ilustra o código de um documento NCL para um melhorentendimento da linguagem. Para maiores informações sobre essa linguagem oleitor deve consultar (Soares & Rodrigues, 2006).