Rafael Ferreira Rodrigues Ambiente Declarativo para Sistemas que

Transcrição

Rafael Ferreira Rodrigues
Ambiente Declarativo para Sistemas que
PUC-Rio - Certificação Digital Nº 0511038/CA
Implementem o GEM
Dissertação de Mestrado
Dissertação apresentada como requisito parcial para
obtenção do título de Mestre pelo Programa de PósGraduação em Informática da PUC-Rio.
Orientador: Luiz Fernando Gomes Soares
Rio de Janeiro, agosto de 2007
Ambiente Declarativo para Sistemas que
Implementem o GEM
Dissertação apresentada como requisito parcial para
obtenção do título de Mestre pelo Programa de PósGraduação em Informática do Departamento de
Informática do Centro Técnico e Científico da PUC-Rio.
Aprovada pela Comissão Examinadora abaixo assinada.
Prof. Luiz Fernando Gomes Soares
Orientador
Departamento de Informática - PUC-Rio
Prof. Renato Cerqueira
Prof. Rogério Ferreira Rodrigues
Prof. José Eugenio Leal
Coordenador Setorial do Centro
Técnico Científico – PUC-Rio
Rio de Janeiro, 20 de agosto de 2007
Todos os direitos reservados. É proibida a reprodução total
ou parcial do trabalho sem autorização da universidade, do
autor e do orientador.
Graduado em Engenharia de Computação pelo Instituto
Militar de Engenharia (IME) em 2004. Atualmente, integra
o grupo de pesquisadores do Laboratório TeleMídia da
PUC-Rio, desenvolvendo pesquisas do GINGA-NCL.
Ficha Catalográfica
Rodrigues, Rafael Ferreira
Ambiente
Declarativo
Implementem o GEM /
Rafael
para
Ferreira
Sistemas
que
Rodrigues
;
orientador: Luiz Fernando Gomes Soares. – Rio de
Janeiro : PUC-Rio, Departamento de Informática, 2008.
101 f. : il. ; 30 cm
Dissertação (mestrado) – Pontifícia Universidade
Católica do Rio de Janeiro, Departamento de Informática.
Inclui referências bibliográficas
1. Informática – Teses. 2. Gem. 3. NCL. 4. Java
5. Ginga 6. TV Interativa. I. Soares, Luiz Fernando
Gomes. II. Pontifícia Universidade Católica do Rio de
Janeiro. Departamento de Informática. III. Título.
CDD: 004
Este trabalho é dedicado: a toda minha família
e amigos, em especial meus pais, Jorge
e Denize, minha irmã Roberta
e minha namorada Juliana.
Agradecimentos
Gostaria de agradecer primeiramente ao meu orientador Prof. Luiz Fernando
pela confiança e pela forma de trabalhar tão inspiradora.
A todos os integrantes do Laboratório TeleMídia que contribuíram direta ou
indiretamente 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 cuja
pesquisa 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. Em
especial 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 de
Informativa da PUC-Rio.
Por fim, gostaria de agradecer ao CNPq, à CAPES, à FINEP e à PUC-Rio
pelo apoio financeiro fornecido ao longo deste mestrado.
Resumo
Rodrigues, Rafael Ferreira. Ambiente Declarativo para sistemas que
implementem o GEM. Rio de Janeiro, 2004. 101p. Dissertação de
Mestrado - Departamento de Informática, Pontifícia Universidade Católica
do Rio de Janeiro.
A existência de vários ambientes procedurais definidos para middlewares de
Sistemas de TV Digital terrestre levou à criação de um framework conhecido
como Globally Executable MHP (GEM). Esse padrão visa a harmonização de tais
ambientes permitindo a execução global das aplicações. Nesse contexto, este
trabalho descreve a construção de um ambiente de apresentação declarativo
utilizando a API fornecida pelo GEM de forma a permitir a execução global do
conteúdo declarativo produzido para o Sistema Brasileiro de TV Digital
Palavras-chave
GEM, NCL, JAVA, Ginga, TV Digital Interativa
Abstract
Rodrigues, Rafael Ferreira. Declarative Environment for Systems
Implementing GEM Rio de Janeiro, 2004. 101p. Master Thesis Departamento de Informática, Pontifícia Universidade Católica do Rio de
Janeiro.
The several procedural environment proposals for terrestrial Digital TV
Systems led to the middleware framework recommendation known as Globally
Executable MHP (GEM). This standard aims at the harmonization of such
environments allowing the global execution of procedural applications but
neglecting the declarative ones. In this context, this work describes the integration
of the Ginga declarative environment using the API supplied by GEM and
allowing the global execution of declarative contents produced for the Brazilian
System of Digital TV (Sistema Brasileiro de TV Digital).
Key words
GEM, NCL, JAVA, Ginga, Interactive TV, Digital TV
Sumário
1 Introdução .............................................................................................. 13
1.1. Motivação........................................................................................... 14
1.1.1. Ambiente Declarativo x Ambiente Procedural ................................ 17
1.2. Objetivos ........................................................................................... 18
1.3. Organização da Dissertação.............................................................. 19
2 Conceitos Preliminares .......................................................................... 21
2.1. Middlewares de TV Digital ................................................................. 21
2.1.1. O Middleware Europeu ................................................................... 23
2.1.1.1. Tipos de aplicações MHP ............................................................ 24
2.1.1.2. O uso de Plug-ins ........................................................................ 26
2.1.1.3. O uso do armazenamento de aplicações .................................... 28
2.1.2. O Middleware Americano................................................................ 29
2.1.3. O Middleware Japonês ................................................................... 31
2.1.4. O Middleware Brasileiro.................................................................. 32
2.2. Definição do padrão GEM.................................................................. 35
2.2.1. Políticas de segurança para execução de aplicativos no GEM .......36
2.2.2. Sinalização de Aplicações no GEM ................................................ 37
2.3. O Blue-Ray Disc ................................................................................ 39
2.4. Ambientes de Execução JAVA para TV ............................................ 40
2.4.1. O Modelo de programação XLET ................................................... 43
3 Trabalhos Relacionados ........................................................................ 47
3.1. O MHP Processando Documentos XHTML....................................... 48
3.2. Ambiente declarativo para TV Digital – UTH ..................................... 49
3.3. Ambiente declarativo para TV Digital – ICECREAM.......................... 50
4 O Fomatador NCL.................................................................................. 52
4.1. O Formatador NCL Java.................................................................... 52
4.2. O GEM processando um documento NCL ........................................ 55
4.3. A Arquitetura de Implantação ............................................................ 57
4.3.1. Estrutura do Sistema Baseada em Componentes.......................... 57
4.4. Adaptações e Otimizações no Formatador NCL ............................... 58
4.4.1. A Pré-conversão de Documentos NCL e o Módulo Gerenciador
de Documentos .................................................................................. 58
4.4.2. Adaptações do Módulo do Núcleo do Formatador ......................... 60
4.4.3. Adaptações do Módulo Gerenciador de Adaptadores para
Exibidores e os Adaptadores Criados....................................................... 63
4.4.4. Adaptações do Módulo Gerenciador de Leiaute............................. 64
5 O Fomatador NCL Xlet ......................................................................... 66
5.1. Os Componentes do Formatador NCL Xlet ....................................... 66
5.1.1. Gerenciador de Leiaute .................................................................. 67
5.1.2. Gerenciador de Documentos .......................................................... 68
5.1.3. Núcleo do Formatador .................................................................... 69
5.1.4. Gerenciador de Adaptador para Exibidores.................................... 70
5.1.5. Adaptadores para Exibidores.......................................................... 70
5.2. Implementação dos Componentes para Sistemas GEM ................... 71
5.2.1. O Carregamento Dinâmico ............................................................. 72
5.2.2. O Módulo de Implantação............................................................... 73
5.2.3. O Processo de Implantação do Formatador ................................... 76
5.2.4. Persistência do Formatador NCL Xlet em Receptores MHP .......... 78
5.3. Testes......... ....................................................................................... 79
6 Conclusões ........................................................................................... 83
6.1.Trabalhos Futuros............................................................................... 84
7 Referências Bibliográficas ..................................................................... 86
Apêndice A Assinatura Digital de um Xlet ................................................ 91
Apêndice B Sinalização de Aplicações..................................................... 94
Apêndice C A Linguagem NCL ................................................................. 98
Lista de Figuras
Figura 1 – O GEM e os demais padrões. ................................................. 16
Figura 2 – Arquitetura de um sistema de TV Digital. ................................ 22
Figura 3 - Perfis MHP. .............................................................................. 24
Figura 4 - Arquitetura básica do MHP....................................................... 25
Figura 5 – Opções de implementação de plug-ins. .................................. 27
Figura 6 – A interface Plugin..................................................................... 28
Figura 7 – Arquitetura do middleware Ginga. ........................................... 34
Figura 8 – O processo de identificação da AIT......................................... 38
Figura 9 – Arquiteturas de plataformas JAVA........................................... 41
Figura 10 – Exemplo de ambiente de execução Java. ............................. 42
Figura 11 – Protocolo entre as entidades presentes no modelo e
programação Xlet...................................................................................... 44
Figura 12 - Interface do Xlet. .................................................................... 44
Figura 13 - Máquina de estados do ciclo de vida de um Xlet. .................. 45
Figura 14 – Interface do XletContext. ....................................................... 45
Figura 15 – Arquitetura da proposta do transcodificador.......................... 48
Figura 16 – Arquitetura do Formatador NCL. ........................................... 53
Figura 17 – Pré-processamento do documento NCL. .............................. 56
Figura 18 – Processamento do documento NCL no receptor................... 56
Figura 19 – Modelo de uma apresentação NCL orientada a sincronização
por contexto. ............................................................................................. 60
Figura 20 – Digrama de classe da interface IFormatter............................ 62
Figura 21 – Diagrama da interface NCLEditingCommandListener........... 63
Figura 22 – Diagrama de classes do modelo de leiaute do Formatador
NCL........................................................................................................... 65
Figura 23 – Duas implementações do componente Gerenciador de
Leiaute ...................................................................................................... 67
Figura 24 – Componente Gerenciador de Documentos. .......................... 68
Figura 25 – Duas implementações do componente do núcleo do
formatador................................................................................................. 69
Figura 26 – Duas implementações do componente do núcleo do
Formatador ............................................................................................... 69
Figura 27 – Duas implementações do componente Gerenciador de
Exibidores ................................................................................................. 70
Figura 28 – Duas implementações de adaptadores para exibidores........ 70
Figura 29 – Classe GingaXlet. .................................................................. 73
Figura 30 – Classe IGingaXletConfiguration............................................. 74
Figura 31 – Interface IGingaXletDeployer................................................. 74
Figura 32 – A classe StreamEventHandler e suas associações. ............. 75
Figura 33 – Diagrama de seqüência do processo de preparação do
Formatador Xlet. ....................................................................................... 77
Figura 34 – Diagrama de seqüência do processo de inicialização do
Formatador Xlet. ....................................................................................... 78
Figura 35 – Digrama de componentes do Sistema testado...................... 80
Figura 36 – Arquitetura de execução distribuída do Formatador NCL. .... 85
Figura 37 – Exemplo de arquivo PRF....................................................... 92
Figura 38 – Estrutura de diretórios de um Xlet. ........................................ 93
Figura 39 – Exemplo de documento NCL 2.0......................................... 101
Lista de Tabelas
Tabela 1 – Componentes do formatador GingaXlet ................................. 80
Tabela 2 – Resultados dos testes de Serialização versus conversão...... 81
Tabela 3 – Plataformas que implementam o CDC. .................................. 84
Tabela 4 – Exemplo resumido de uma tabela AIT.................................... 95
Tabela 5 – Parâmetros adicionais da AIT para sinalização do Formatador
Xlet............................................................................................................ 96
1
Introdução
A 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 oportunidades
capaz de proporcionar uma maior interatividade para o telespectador. Essa
integração
permite
que
a
programação
seja
enriquecida
através
da
disponibilizaçã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. Essa
possibilidade, contudo, exige um maior poder computacional da parte dos
receptores do sinal de TV digital para que, desta forma, tenham a capacidade de
executar as aplicações para eles desenvolvidas.
Devido à enorme diversidade de fornecedores de terminais de acesso, tornase necessária, a fim de promover uma execução global das aplicações
desenvolvidas pelos produtores de conteúdo, a criação de uma abstração
denominada middleware. O middleware fornece um conjunto comum de
Interfaces 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 seguintes
padrões de middleware figuram como principais:
1. O europeu, denominado Multimedia Home Platform (MHP) (ETSI,
2005b), definido pelo grupo do DVB (Digital Video Broadcasting
Project);
2. O
americano,
conhecido
como
DTV
Application
Software
Environment (DASE) (ATSC, 2003a), definido pelo grupo ATSC
(Advanced Television Systems Committee); e
3. O japonês, Integrated Services Digital Broadcasting (ISDB) (ARIB,
2004), definido pelo grupo ARIB (Association of Radio Industries
and Businesses).
Introdução
14
No âmbito brasileiro, encontra-se em desenvolvimento o middleware a ser
utilizado pelo sistema de TV digital deste país, batizado como Ginga, e parte do
Sistema Internacional para Difusão Digital Terrestre (Terrestrial International
System for Digital Broadcasting – ISDB-T), também conhecido como SBTVD.
1.1.
Motivação
O middleware europeu MHP, que contou com uma rápida popularização,
adotou em seu ambiente procedural a linguagem JAVA (Gosling, 1996). Com
isso, foi criado um nível maior de portabilidade para suas aplicações, permitindo o
reuso de componentes de software provenientes de outras plataformas. Surgiram,
então, algumas iniciativas para sua implementação sobre outras plataformas
internacionais. Entidades responsáveis pela padronização de sistemas de TV
Digital, fora da Europa, manifestaram o interesse em ter parte do middleware
MHP implementado em suas especificações. Dessa forma, seria aproveitado todo
seu desenvolvimento tecnológico e mantida uma compatibilidade que permitisse
que as novas aplicações, como aquelas já desenvolvidas, pudessem ser
executadas/apresentadas em terminais de acesso desses outros padrões.
Diante do interesse em se fazer uma integração entre os middlewares
procedurais já existentes surgiu, então, o Globally Executable MHP (GEM)
(ETSI, 2005a). O GEM, que pode ser considerado como um acordo de
harmonização entre os principais padrões existentes, tem como base o MHP. Isso
porque, além de capturar um subconjunto das interfaces, e toda a semântica
definida por este padrão de middleware, o GEM também inclui as necessidades
impostas por outros padrões internacionais.
Com o GEM despontando como ambiente de execução procedural mínimo
para os principais padrões de TV Digital (MHP, DASE e ARIB) e de mídia
empacotada (como o Blue-Ray Disc), tem-se aí uma base para a criação de
aplicações e programas interativos portáveis para diversas plataformas.
Middlewares procedurais compatíveis com a especificação do GEM vêm sendo
adotados por vários países no mundo todo (MHP, 2006), inclusive pelo Brasil.
Contudo, no GEM, como mencionado, é definido apenas um ambiente de
execução procedural, deixando livre para a implementação a definição de um
15
Introdução
possível ambiente declarativo. Na Figura 1 são mostradas as especificações de
ambientes declarativos adotados pelos principais padrões que implementam o
GEM. 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 uma
tendência de harmonização que já vinha sendo demonstrada desde o
estabelecimento do GEM. A recomendação ITU-T J.200 (ITU-T, 2001) foi criada
visando promover uma arquitetura de alto nível para um conjunto de formatos e
APIs mais harmônicos, capazes de prover várias funcionalidades necessárias para
aplicações interativas mais avançadas a serem oferecidas pelas redes de televisão
para os usuários domésticos. É o núcleo comum dos ambientes de aplicação para
serviços de TV Digital interativa. A recomendação estabelece tanto um ambiente
de execução declarativo (detalhado em ITU J.201) (ITU-T, 2004) quanto
procedural (detalhado em ITU-T J.202) (ITU-T, 2003). Contudo, esses ambientes
não precisam ser necessariamente independentes; podendo ser definidas pontes
entre eles.
A Figura 1 mostra a especificação ITU-T J.201 como compreendendo todo
o ambiente declarativo das três principais implementações de middleware. Apesar
da especificação prever um núcleo comum, mostrado no centro da área
pontilhada, é prevista sua extensão para certos requisitos específicos da
implementaçã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 pelo
W3C (W3C, 1998);
•
A API DOM para alterar dinamicamente o conteúdo dos
documentos 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 do
ambiente procedural prevê um núcleo comum que é justamente o framework
proposto pelo GEM. A especificação também permite a extensão desse núcleo
Introdução
16
comum apresentando, em caráter informativo, os três padrões anteriormente
mencionados.
Figura 1 – O GEM e os demais padrões.
Embora exista uma tendência clara à harmonização do middleware
procedural, realizada pelo GEM, o mesmo não se pode dizer, de fato, com relação
ao middleware declarativo. Apesar dos três padrões da Figura 1 adotarem um
ambiente baseado no padrão XHTML, com exceção do sistema japonês, esses
ambientes ainda não foram comercialmente implementados a contento.
As limitações do modelo XHTML, a serem discutidas a seguir, e a falta da
implementação de um ambiente declarativo encorajam a criação de novos
mecanismos 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 API
procedural comum estabelecida pelo GEM.
Na definição do subsistema declarativo do middleware brasileiro foi
padronizada a utilização da linguagem NCL (Nested Context Language –
Linguagem de Contextos Aninhados) (Soares & Rodrigues, 2006). Ao contrário
dos padrões citados anteriormente, a NCL possui o foco no sincronismo de mídias
e não é baseada no padrão XHTML. No entanto, essa linguagem mantém a
compatibilidade com os demais padrões por permitir a definição de um exibidor
Introdução
17
XHTML que viabiliza a utilização de conteúdo desta natureza como mídia a ser
sincronizada pelo documento NCL.
Apesar de ser possível a reprodução do conteúdo declarativo dos demais
padrões pelo middleware brasileiro, o contrário não é possível. De forma a
viabilizar tal compatibilidade, uma das alternativas é utilizar a API procedural
fornecida pelos padrões internacionais para a criação de um ambiente de
apresentação declarativo para documentos NCL, que é o foco principal desta
dissertação.
1.1.1.
Ambiente Declarativo x Ambiente Procedural
Em um sistema de TV digital, um ambiente de execução procedural é
aquele capaz de executar programas criados seguindo o paradigma de
programação imperativo. Esses códigos apóiam-se, basicamente, na execução
algorítmica de instruções fornecidas pelo programador. Dessa forma, o
programador possui um maior controle da execução, sendo capaz de estabelecer
todo o fluxo de controle e execução de seu programa. Contudo, é necessário que o
programador seja mais qualificado e conheça bem os recursos da linguagem.
Ambientes de apresentação declarativos, por sua vez, executam códigos
criados seguindo o paradigma de programação declarativo. No âmbito dos quatro
padrões anteriormente mencionados, incluindo o brasileiro, suas linguagens
declarativas são todas baseadas em XML (eXtensible Markup Language). Entre
os exemplos de linguagens declarativas baseadas em XML (chamadas de
aplicações XML) encontram-se a linguagem NCL (Nested Context Language –
utilizada pelo SBTVD-T), a linguagem SMIL (Synchronized Multimedia
Integration 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 do
problema em implementações algorítmicas, a linguagem declarativa enfatiza a
declaração descritiva da solução do problema. A linguagem declarativa é mais
indicada para aplicações cujo foco casa com o objetivo específico para o qual a
linguagem 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
18
carregadas 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 principal
são exemplos de relacionamentos comuns entre objetos presentes nessas
aplicações.
1.2.
Objetivos
Este trabalho tem como objetivo propor um ambiente de apresentação de
programas declarativos desenvolvidos na linguagem NCL para sistemas que
implementem o GEM.
No ambiente “virtual” implementado são utilizadas apenas as APIs JAVA
fornecidas pelo framework GEM. Seu desenho foi concebido de forma a ser capaz
de operar sobre plataformas de recursos limitados.
A solução proposta tem como base o Formatador NCL da implementação de
referência do middleware Ginga realizada pelo Laboratório TeleMídia da PUCRio. Contudo, foi necessária uma adaptação da implementação existente para
desktops, no intuito de permitir a compatibilidade com o GEM, sem perder
contudo a conformidade com o ambiente declarativo do Ginga.
Além do formatador, alguns de seus exibidores de mídia também foram
adaptados.
Como uma das grandes dificuldades encontradas ao se executar aplicações
em ambientes de TV Digital é o seu tempo de iniciação, foram pesquisados
mecanismos para otimização do tempo de iniciação da execução do documento.
Um destes mecanismos é o carregamento modular do formatador. No
desenvolvimento realizado, apenas os módulos do formatador necessários para a
apresentaçã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 detrimento
daquele transportado no fluxo MPEG-2 Sistema. Para realizar o processo de
implantação de tais módulos, foi criada uma estrutura independente. Essa
estrutura possui a capacidade de abstrair dos demais módulos o acesso ao fluxo
Introdução
19
MPEG-2 para o carregamento de bibliotecas e outros recursos necessários para a
apresentação de um documento hipermídia.
Outro mecanismo de otimização utilizado é a pré-conversão do documento
NCL. Esse mecanismo visa diminuir o número de etapas necessárias pelo receptor
para iniciar a execução de um documento, além de eliminar a necessidade de uma
biblioteca para o processamento de documentos XML.
1.3.
Organização da Dissertação
O restante desta dissertação encontra-se organizada como a seguir. No
Capítulo 2 são expostos conceitos acerca dos principais middlewares procedurais
existentes sendo, a seguir, apresentado o GEM como harmonização de tais
middlewares. Após a apresentação do GEM é mostrado o primeiro padrão de
mídia empacotada a implementá-lo: o Blue-Ray Disc. É trazida, então, ao
conhecimento do leitor a recomendação da máquina virtual Java mínima para
ambientes procedurais de sistemas de TV Digital. A seguir, são apresentadas as
tecnologias envolvidas na construção de um ambiente declarativo para sistemas
que 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 middlewares
declarativos baseados no XHTML como aplicações dos middlewares procedurais
correspondentes. A seguir, são discutidas duas aplicações para TV Interativa que
fazem uso de uma máquina de apresentação de documentos SMIL no ambiente de
execução do middleware MHP. Ao final do capítulo, são apresentados os
resultados de testes realizados por uma implementação SMIL em um sistema de
broadcast de TV Digital.
O Capítulo 4 apresenta a implementação Java do Formatador NCL
desenvolvida pelo laboratório de Telemídia da PUC-Rio e que serviu como base
para a elaboração deste trabalho, uma vez que o foco desta dissertação está na
especialização do Formatador NCL como uma aplicação GEM. A seguir, são
mostradas todas as adaptações necessárias à implementação Java do Formatador
NCL para a execução em um ambiente compatível com o GEM.
Introdução
20
O Capítulo 5 apresenta uma proposta de um ambiente declarativo baseado
na linguagem NCL para sistemas que implementem o GEM. Nesse capítulo é
descrita a arquitetura e a implementação do sistema proposto. É mostrado como
integrar tal implementação a sistemas MHP utilizando as facilidades introduzidas
por sua interface de plug-ins e armazenamento de aplicações. Ao final do
capítulo, são apresentados os resultados de alguns testes realizados.
O Capítulo 6 apresenta uma análise dos resultados obtidos e sugestões para
suscitar trabalhos futuros.
2
Conceitos Preliminares
No capítulo anterior foram citados os três middleware para TV Digital
terrestre 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ções
procedurais em sistemas de mídia empacotada: o Blue-Ray Disc. Tais padrões
estabelecem uma série de requisitos mínimos a serem implementados por seus
terminais. Neste capítulo são mostrados alguns desses requisitos relevantes para a
construção de um ambiente de apresentação declarativo como uma aplicação
procedural. É também feita uma breve descrição dos padrões mencionados, que
constituem as plataformas para as quais o sistema proposto é destinado.
No intuito de descrever melhor as tecnologias envolvidas na construção do
sistema proposto, este capítulo mostra, também, a configuração mínima de uma
máquina virtual Java para uma plataforma de TV Digital.
Para cumprir seus propósitos, este capítulo está organizado da forma a
seguir. Na Seção 2.1, e em suas subseções, são apresentados os principais
middleware procedurais para TV Digital aberta. A Seção 2.2 descreve o GEM
como tentativa de harmonização desses padrões de middleware. A Seção 2.3
mostra o padrão Blue-Ray: o primeiro padrão de mídia empacotada a implementar
o GEM. E, por fim, na Seção 2.4 é apresentada a especificação mínima do
ambiente Java para sistemas de TV digital, inclusive o GEM.
2.1.
Middlewares de TV Digital
Numa arquitetura de serviços para TV Digital, o middleware consiste em
uma abstração que atua entre duas camadas bem definidas. A razão de sua
existê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ção
formal, podendo ser especificada de acordo com os critérios do fabricante do
22
receptor. 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 aos
usuá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 provedores
de conteúdo/infra-estrutura.
De forma a permitir que os aplicativos e serviços do sistema de TV Digital
sejam desenvolvidos independente da camada inferior, ou seja, do fabricante, foi
criada uma camada intermediária: o middleware.
Os middlewares são padrões que especificam requisitos mínimos a serem
implementados pelos fabricantes de forma a permitir uma execução global de
aplicações e serviços para TV Digital. Tal padronização abrange, principalmente,
APIs para acesso aos recursos da camada inferior, protocolos e formatos de
conteúdo a serem suportados.
Figura 2 – Arquitetura de um sistema de TV Digital.
A Figura 2 ilustra o middleware exercendo seu papel de camada
intermediária entre o sistema operacional e os aplicativos e serviços comuns aos
usuários do sistema de TV Digital.
Os principais padrões de middleware para sistemas de TV Digital terrestre
serão descritos nas seções a seguir.
23
2.1.1.
O Middleware Europeu
O middleware europeu MHP (Multimedia Home Platform) foi desenvolvido
por 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 ao
ETSI (European Telecommunications Standards Institute – um órgão responsável
por 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 os
quais elas são dirigidas, definindo sua área de abrangência e, como conseqüência
requisitos de processamento e comunicação dos terminais; e o segundo enquadra
as 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.1
na ordem do mais básico ao mais avançado, sendo que cada perfil é uma extensão
do perfil imediatamente mais básico:
• Enhanced Broadcast Profile: É o perfil básico, projetado para
espelhar as funcionalidades fundamentais existentes em um sistema
de middleware. Nesse perfil não existe interatividade direta com os
provedores 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 um
canal de retorno. Esse perfil apresenta suporte para comunicação IP
sobre o canal de retorno. Além disso, existe também grande suporte
para interatividade com as APIs definidas;
• Internet Access Profile: Esse perfil fornece grande poder de
processamento e armazenamento, permitindo acesso a conteúdo da
Internet no terminal de acesso. É previsto, obrigatoriamente, a
existência de um cliente de e-mail e um browser HTML sem, no
entanto, tornar obrigatória a extensão promovida pela linguagem
DVB-HTML (apresentada na próxima seção).
24
A Figura 3 apresenta os perfis citados ilustrando algumas das APIs e
tecnologias suportadas por cada versão do MHP.
Figura 3 - Perfis MHP.
2.1.1.1.
Tipos de aplicações MHP
As aplicações MHP declarativas e procedurais são, respectivamente, o
DVB-HTML e DVB-J (ou DVB JAVA). As aplicações DVB-HTML não são
muito difundidas pelo fato de terem sido especificadas apenas na última versão do
padrão. Já as aplicações DVB-J possuem grande aceitação no mercado, pois as
APIs de suporte são obrigatórias em todos os perfis.
Uma aplicação MHP, no entanto, não necessariamente precisa ser
exclusivamente procedural ou declarativa. Existem ainda, como mostrado na
Figura 4, as aplicações híbridas. Nessas aplicações é prevista a existência de
elementos em ambas as linguagens, denso prevista uma ponte que permite a
25
comunicação entre as aplicações que pertençam a esses dois paradigmas
diferentes.
Figura 4 - Arquitetura básica do MHP
Aplicações DVB-HTML são baseadas em alguns padrões estabelecidos pelo
W3C. Essas aplicações são descritas em uma linguagem que estabelece uma
extensão ao XHTML adotando, em conjunto com este, os padrões, Cascade Style
Sheets (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 do
ECMAScript, 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 destinada
a desktops, devendo obedecer a uma série de APIs mais restritivas definidas pelo
MHP (ETSI, 2005). São elas:
•
JavaTV: Introduz uma série de funcionalidades específicas para o
ambiente de TV interativa, como localização de conteúdo, controle do
ciclo de vida da aplicação, controle de acesso, sintonização e
informação sobre serviços. Os programas que utilizam essa API são
também denominados Xlets.
•
JMF: O Java Media Framework é uma API que gerencia o
comportamento e a interação de objetos de mídia contínua. JMF é
26
utilizado para capturar, processar e apresentar alguns tipos de mídias
contínuas.
•
HAVi User-Interface: é uma API que permite ao programador criar
elementos 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 para
prover interoperabilidade fim-a-fim;
•
DVB-MHP: Essa API utiliza os serviços providos pelas classes das
APIs já mencionadas (ou seja, na prática provendo a mesma
funcionalidade) e adiciona serviços novos, como gerenciamento da
conexão do canal de retorno, armazenamento de informações,
manipulação de eventos, segurança, gerenciamento de aplicações e
carregamento de plug-ins.
O MHP fornece dois mecanismos auxiliares que permitem a instalação de
aplicações de forma persistente nos receptores dos usuários. São eles: o uso dos
plug-ins e o Application Storage (armazenamento de aplicações). Nas subseções
seguintes serão apresentados esses dois mecanismos.
2.1.1.2.
O uso de Plug-ins
Plug-ins são conjuntos de funcionalidades que podem ser adicionadas a uma
plataforma genérica de forma a prover a interpretação de formatos de aplicação
registrados junto ao DVB. Atualmente, encontram-se registrados dois formatos de
aplicações: o HTML 3.2, que também indica aplicações no formato XHTML e
suas derivadas como o DVB-HTML, e o MHEG-5 (ISO, 1997). A Figura 5
mostra os dois tipos possíveis de plug-ins: nativos (na figura como plug-in B) e
interoperá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 na
linguagem Java, desde que não sejam utilizadas as APIs do MHP, caso contrario,
27
deixam de ser considerados nativos. O processo de sinalização das aplicações1,
tanto do plug-in como das aplicações por ele processadas, também deverá ser
nativo.
Figura 5 – Opções de implementação de plug-ins.
Já um plug-in interoperável é aquele que necessita apenas das APIs
especificadas pelo padrão MHP, permitindo dois tipos de sinalização: uma
fornecida 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 dois
tipos de descritores a serem utilizados pela tabela AIT: um descritor de aplicação
para o plug-in e outro para a aplicação por ele processada. Esses descritores são
mostrados em mais detalhes no Apêndice B. A sinalização prevê, ainda, que o
ponto de entrada do plug-in seja uma classe que implemente a interface
org.dvb.application.plugins.Plugin
mostrada na Figura 6. Com isso, as
aplicações processadas por ele serão reconhecidas como Xlets e controladas pelo
Gerenciador de Aplicações.
Na sinalização específica da implementação, a aplicação processada pelo
plug-in não será reconhecida como uma aplicação MHP (Xlet). Com isso todo seu
controle (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 associadas
a um serviço. Ela deve também oferecer mecanismos pelos quais as difusoras possam gerenciar o
ciclo de vida de suas aplicações.
28
public 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 Figura
6, visa, como mencionado, permitir ao Gerenciador de Aplicações manter o
controle do ciclo de vida das aplicações sendo executadas pelo plug-in
interoperável. Para isso, essa interface reusa o modelo de programação Xlet de
forma a representar aplicações em formatos diferentes do DVB-J.
A classe que implementar essa interface não poderá realizar nenhuma
operação que consuma muito processamento em seu construtor. Todas as rotinas
de 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 para
iniciar 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 a
aplicação possa ser tratada pelo plug-in. O método terminatePlugin será chamado
ao término da execução da aplicação.
A grande vantagem introduzida por essa facilidade é o fato de uma
aplicação de conteúdo genérico ser sinalizada para os receptores e interpretada
por eles como uma aplicação MHP (Xlet). Isso contribui para a adoção do padrão
DVB-HTML para aplicações declarativas, permitindo sua introdução como plugin MHP nos perfis Enhanced Broadcast e Interactive Broadcast (Perrot, 2001).
2.1.1.3.
O uso do armazenamento de aplicações
A especificação do MHP prevê uma API opcional denominada
Application Storage. Os receptores que implementam tal API são capazes de
interpretar um tipo de sinalização de aplicação que permite o armazenamento de
programas. Esse mecanismo provê uma série de vantagens:
•
Permite a aplicação armazenada seja iniciada a qualquer momento
pelo usuário ou pela difusora;
•
Permite o controle de versão da aplicação;
•
29
Permite a instalação automática de aplicações sem a necessidade
de 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 seria
possível, também, armazenar aplicações. Contudo, tornaria necessário o envio
prévio de outra aplicação para executar o carregamento das aplicações originais
do disco.
Mais informações sobre o mecanismo de sinalização do MHP podem ser
encontradas no Apêndice B.
2.1.2.
O Middleware Americano
O Advanced Television Systems Committee (ATSC) é uma organização
americana responsável por estabelecer padrões para TV. Esse comitê foi formado
inicialmente pela Electronic Industries Association (EIA), Institute of Electrical
and Electronic Engeneers (IEEE), National Association of Broadcasters (NAB),
National Cable Television Association (NCTA) e Society of Montion Picture and
Television Engineers (SMPTE).
Inicialmente, foi desenvolvido pelo ATSC um padrão denominado DTV
Application Software Environment Level 1 (DASE-1). O DASE adota modelos de
aplicações baseados em linguagem procedural e declarativa. No ambiente
declarativo é 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 DASE
ní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 de
retorno, foi estabelecida uma integração da TV com a internet, dando acesso a
programas de correio eletrônico, navegadores web entre outros, no terminal de
acesso.
Paralelamente a essa iniciativa, desenvolveu-se o OpenCable Applications
Plataform (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
30
com o ambiente procedural para execução de aplicações denominadas OCAP-J e
desenvolvidas para plataforma JAVA.
Dado o cenário mencionado, com dois tipos de middleware despontando no
território americano e a clara tendência à harmonização proposta pelo GEM, o
ATSC introduziu a especificação do Advanced Common Application Plataform
(ACAP).
Middleware Americano ATSC/ACAP
O padrão ACAP surgiu a partir de um trabalho em conjunto com
participantes do DVB em setembro de 2004. Sua especificação é primariamente
baseada no GEM e no DASE e inclui funcionalidades adicionais do OCAP. Ela
foi criada com o intuito de substituir o DASE e permitir uma compatibilidade com
o GEM e com o OCAP. Dessa forma, além de permitir a criação de aplicações
portáveis dentre os middlewares americanos e os compatíveis com o GEM, o
padrão permite uma compatibilidade com as aplicações já existentes em território
americano.
As aplicações ACAP são classificadas em duas categorias: conteúdos
procedurais ou conteúdos declarativos. As aplicações contendo apenas conteúdo
procedural são denominadas ACAP-J e as contendo conteúdo declarativo ACAPX. Similar ao MHP, o ACAP classifica as plataformas que o implementam em
dois perfis: o perfil ACAP-J, no qual a plataforma é obrigada a implementar
apenas o suporte às aplicações procedurais; e o perfil ACAP-J e ACAP-X, que
obriga a plataforma a dar suporte a programas procedurais, declarativos e
híbridos. Esse enquadramento torna a existência de um ambiente declarativo
facultativo e reforça a idéia de compatibilidade com o GEM.
No ambiente ACAP-X, as aplicações são representadas por documentos
hipermídia compostos por meio de uma linguagem de marcação (e.g. XHTML),
regras de estilo (CSS), scripts (ECMAScritpt), Xlets embutidos (aplicações
ACAP-J), e elementos audiovisuais. Toda a definição desse ambiente é baseada
em 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
31
sã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 do
ambiente 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 ainda
quase nenhuma penetração sua dentre os consumidores americanos.
Middleware Americano CableLabs/OCAP
A especificação OCAP 1.0 foi estabelecida em 2001. No entanto, apesar do
estabelecimento da proposta de middleware ACAP pelo ATSC, a evolução do
OCAP continuou a ocorrer paralelamente. Depois de algumas revisões, o padrão
passou 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. Depois
disso, acompanhando a evolução do GEM, em 2006 foi lançado o OCAP 1.1
correspondendo ao DVB-GEM 1.1 e DVB-MHP 1.1.2.
2.1.3.
O Middleware Japonês
A especificação do sistema para transmissão digital terrestre japonês foi
produzida 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 uma
aprovação final pelo governo Japonês. Tal especificação estabeleceu o padrão
conhecido como Terrestrial Integrated Services Digital Broadcasting (ISDB-T).
32
Assim como na maioria dos demais sistemas, a arquitetura ARIB é
composta por dois subsistemas: um para a execução de programas procedurais; e
outro para a apresentação de programas declarativos. Entretanto, no padrão
japonês não foram definidos elementos capazes de estabelecer uma ponte entre
esses dois subsistemas.
A linguagem utilizada no ambiente declarativo é denominada BML
(Broadcast Markup Language). Essa linguagem encontra-se definida na
especificação ARIB STD-B24 Volume 2 (Data Coding and Transmission
Specification for Digital Broadcasting Vol. II). Ela baseia-se no XHTML e
fornece suporte a CSS e ECMAScript.
No BML, o ECMAScript foi estendido de forma a fornecer uma API capaz
de 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 ARIB
STD-B23 (Application Execution Engine Platform for Digital Broadcasting) em
2003. 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 bytecode
JAVA 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 maior
penetração de aplicações declarativas e receptores que implementem suporte a tal
paradigma. Isso se deve, possivelmente, ao fato da padronização tardia do
ambiente procedural.
2.1.4.
O Middleware Brasileiro
A proposta para o middleware utilizado pelo ISDTV-T, cuja arquitetura é
mostrada na Figura 7, compreende a implementação de dois subsistemas:
•
33
Um provê uma infra-estrutura para a execução de aplicações
baseadas 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ções
baseadas em documentos hipermídia escritos na linguagem
declarativa NCL, sendo denominado Ginga-NCL (ilustrado na
figura à esquerda da ponte).
No entanto, as aplicações não necessitam ser exclusivamente procedurais ou
declarativas. Existem elementos em ambos os subsistemas que permitem a
construção de aplicações híbridas: uma aplicação declarativa (NCL) pode possuir
outra aplicação procedural embutida; ou, por outro lado, uma aplicação
procedural pode referenciar o conteúdo declarativo, como, por exemplo, criando e
iniciando apresentações.
O uso da linguagem NCL em ambientes de TV Digital interativa visa
garantir o sincronismo quando da reprodução de programas interativos
multimídia, hipermídia e não-lineares. A entidade responsável pela apresentação
de documentos NCL é denominada Formatador NCL.
A partir da especificação do documento NCL recebida, o Formatador
constrói um plano de apresentação que contém as características de apresentação
de cada objeto de mídia, a programação das tarefas a serem escalonadas e as
informações dos relacionamentos de sincronização entre os objetos de mídia.
Baseado nos eventos gerados pelos exibidores de mídia e nos eventos gerados
pelo usuário, o escalonador de apresentação controla a execução sincronizada de
todo o documento, realizando ajustes quando esses se fazem necessários
(Rodrigues, 2003).
Na Figura 7 são mostrados, ainda, dois exibidores que devem ser
implementados pelo middleware: o exibidor XHTML, que deve possuir um
interpretador 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 o
middleware 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.
34
Para que outros tipos de conteúdo, além dos citados anteriormente, possam
ser apresentados no ambiente declarativo, é necessária a criação de adaptadores
que respeitem a API de Adaptadores do Formatador. Essa API permite que os
exibidores desses outros tipos de conteúdo sejam controlados de acordo com o
modelo 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áveis
por armazenar documentos NCL. Tais estruturas são denominadas privadas
devido 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 assegurar
o 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 um
documento NCL durante sua apresentação.
Figura 7 – Arquitetura do middleware Ginga.
O subsistema procedural (Ginga-J) constitui uma extensão à especificação
do GEM, mantendo, dessa forma, a compatibilidade com todos os demais padrões
que implementam tal especificação (DVB MHP, ATSC ACAP e OCAP, ISDB
ARIB). A API proposta pelo Ginga-J pode ser dividida em três porções: a porção
definida pelo GEM; a porção definida pelo Ginga-J mas adaptável ao GEM; e a
porção definida apenas pelo Ginga-J.
35
Dentre as inovações introduzidas pelo subsistema procedural do middleware
brasileiro, pode-se destacar o suporte a interações multiusuário, multidispositivo e
multi-rede de comunicação, com o receptor (Filho et al., 2007).
Abaixo desses dois subsistemas lógicos (Ginga-NCL e Ginga-J) existe uma
camada, que lhes oferece suporte, denominada Núcleo Comum. Essa camada é
composta por decodificadores comuns de conteúdo (como PNG, JPG, GIF ou
MPEG) e rotinas para obter conteúdos transportados no Fluxo de Transporte
MPEG-2 (ISO, 1993) e via canal de retorno. Possui ainda uma Máquina Virtual
Java (JVM – Java Virtual Machine) para a execução de códigos binários dessa
linguagem.
2.2.
Definição do padrão GEM
O GEM (Globally Executable MHP) foi proposto, inicialmente, para que as
aplicações MHP pudessem ser utilizadas sobre as plataformas do middleware dos
EUA (CableLabs) e do Japão (ARIB). O GEM é considerado um acordo de
harmonização. Isso porque, além de capturar as interfaces e toda a semântica
definidas pelo MHP (independentes da plataforma DVB), o GEM inclui as
necessidades impostas por outros padrões internacionais. A CableLabs participou
da composição da primeira versão do GEM, para tornar compatível seu
middleware para a TV a cabo americana, o OCAP. E, mais recentemente, o
middleware japonês ARIB e o candidato a padrão americano ACAP também
tiveram 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ção
completa para terminais de acesso. O correto é dizer que GEM é um framework a
partir 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 uma
conformidade que garante a execução global de aplicações. O padrão define,
portanto, um conjunto de APIs, garantias semânticas, protocolos e formatos de
conteúdo com os quais as aplicações (agora globalmente interoperáveis) podem
contar para a constituição de serviços interativos, executáveis em qualquer
plataforma definida pelos padrões internacionais compatíveis.
36
Por definir um framework baseado no padrão MHP, o documento de
especificação do GEM é na realidade uma listagem de referências a outros
documentos do consórcio DVB. Ele descreve as diversas partes do MHP que são
independentes do padrão DVB e salienta aquelas que devem ser substituídas de
acordo com a infra-estrutura de implementação das novas especificações
compatíveis. Esses pontos de flexibilização do GEM devem ser, então,
preenchidos por “equivalentes funcionais” – mecanismos que lançam mão de
outras tecnologias (definidas pelas respectivas organizações de TV digital) para
implementar uma funcionalidade análoga àquela proposta pelo DVB. Tais
tecnologias passam a ser qualificadas como equivalentes funcionais somente após
negociações entre o consórcio DVB e cada uma das organizações que requisitam
a 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 GEM
Todo 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 uma
aplicação. De acordo com o padrão, as aplicações que são enviadas para um
receptor serão classificadas como não confiáveis e não possuirão acesso a toda a
API Java.
Para garantir um nível maior de confiabilidade à aplicação, é necessária sua
assinatura digital. Uma aplicação assinada pode ter suas permissões de acesso
alteradas através de um Arquivo de Requisição de Permissão (Permission Request
File – PRF).
Os PRFs são arquivos XML que devem estar presentes no mesmo diretório
do arquivo inicial de uma aplicação que necessite de alterações em seu nível de
acesso padrão. Nesses arquivos, o identificador formal da DTD deve corresponder
à organização que especificou o documento. Além disso, o prefixo do PRF deve
identificar
a
especificação
de
terminal
GEM
(Ex.:
37
ocap.<nome_do_aplicativo>.perm). Um exemplo de tal arquivo pode ser
encontrado 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, uma
lista 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 mais
relevantes disponíveis para utilização em um PRF e necessárias para a
implementação de um ambiente declarativo virtual são:
org.dvb.net.tuning.TunerPermission: permissão para realizar a
•
troca entre os fluxos;
org.dvb.user.UserPreferencePermission:
•
permissão
para
leitura/escrita das preferências do usuário. Sendo a leitura permitida
também para aplicativos não-assinados;
java.net.SocketPermission: permissão para se comunicar com hosts
•
remotos (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
para
controlar o ciclo de vida da aplicação;
org.dvb.net.rc.RCPermission:
•
permissão
para
comunicação
utilizando o canal de retorno (connect, listen, resolve).
2.2.2.
Sinalização de Aplicações no GEM
Na especificação do GEM são fornecidos requisitos mínimos de
sinalização que devem ser implementados pelos padrões baseados nessa
especificação:
•
para qualquer aplicação: seu descritor deve possibilitar a
identificação do nome da aplicação; o identificador único da
38
aplicação e da organização que a produziu; e a localização da
aplicação e demais arquivos por ela utilizados; e
•
para aplicações procedurais (e.g. Java): deve ser fornecida
informação suficiente para sinalizar os parâmetros da aplicação e
indicar sua classe inicial.
Uma forma de implementar tais mecanismos é utilizando a Tabela de
Informação de Aplicações (Application Information Table – AIT). Toda a
informação sobre as aplicações que podem ser obtidas via carrossel de objetos ou
via canal de retorno são armazenadas nessa tabela. Ela é enviada em conjunto
com outros fluxos elementares em um fluxo de transporte MPEG-2.
Na Figura 8 é mostrado o processo de identificação da AIT em um fluxo
de transporte MPEG-2. A Tabela de Associação de Programas (Program
Association Table – PAT) pode ser encontrada nos pacotes de fluxo de transporte
identificados pelo PID 0. Supondo que a AIT da aplicação está associada com o
programa 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 fluxo
possuir o valor 0x05, que representa o fluxo do tipo AIT, então os pacotes com o
PID 0x200 estarão carregando a AIT correspondente a esse programa.
Figura 8 – O processo de identificação da AIT.
39
No Apêndice B é ilustrada como é formada a AIT em um sistema de TV
Digital que utilize o DVB-MHP.
2.3.
O Blue-Ray Disc
O disco Blue-Ray (BD – Blue-Ray Disc) é uma revolução em termos de
armazenamento em mídia ótica para consumidores de produtos eletrônicos, PCs e
consoles de vídeo game (Playstation 3). Ele proporciona: uma resolução de alta
definição de 1920 x1080, comparada aos 720x480 proporcionados pelo DVD e os
352x240 pela TV analógica; e uma capacidade de armazenamento de 25GB e 50
GB, atualmente, e até 200GB, com o lançamento futuro de discos multicamadas.
Com relação à interatividade, para uma plataforma BD encontram-se
definidos dois modos de operação que podem, inclusive, coexistir:
•
High Definition Movie (HDMV) – esse modo enfatiza uma
compatibilidade com os processos de produção dos DVDs atuais. O
modo HDMV suporta todas as funcionalidades proporcionadas pelos
DVDs atuais e seus formatos. Contudo, proporciona melhoras na
qualidade do vídeo, áudio, definição, experiência do usuário, entre
outros; e
•
BD-J – um ambiente de aplicações programáveis com possibilidades
de canal de retorno, possibilitando aos produtores de conteúdo uma
alta interatividade e títulos BD-ROM atualizáveis.
Foi estabelecida pela BDA (Blue-ray Disc Association) a linguagem JAVA
como tecnologia a ser adotada em aplicações BD-J. Isto possibilita a criação de
aplicações com interatividade avançada proporcionando-se as seguintes vantagens
ao 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 de
conteúdo (jogos interativos no disco e online, eventos ao vivo, compras online).
Ao adotar como linguagem o JAVA, a BDA, buscando seguir a tendência
global de harmonização dos ambientes de execução procedural para sistemas de
TV digital, estabeleceu que as plataformas BD deveriam implementar o
framework GEM.
40
Seguindo a especificação do GEM, o padrão BD-J também define dois
perfis para suas aplicações:
•
BD-VIDEO – esse perfil não requer canal de retorno; e
•
BD-LIVE – esse perfil requer canal de retorno proporcionando o
download de conteúdos e aplicações novas.
2.4.
Ambientes de Execução JAVA para TV
Um ambiente de execução Java (Java Runtime Environment – JRE) é uma
implementação da tecnologia Java para uma plataforma específica. Ele é instalado
e executado como uma aplicação nativa com o propósito de executar e gerenciar
aplicativos JAVA. O JRE fornece, portanto, uma abstração comum para as
aplicações JAVA e é implementado em código nativo.
A tecnologia Java pode ser subdividida como mostra a Figura 9. Esta
divisão procura enquadrar essa tecnologia em algumas plataformas-alvo:
•
A edição Java EE (antiga J2EE) é voltada para o segmento dos
servidores, é uma edição que possui recursos avançados para
aplicações empresariais;
•
A edição Java SE (antiga J2SE) é a edição padrão recomendada para
a maioria das plataformas, incluindo, principalmente, desktops; e
•
A edição Java ME (antiga J2ME) é a edição para plataformas com
recursos 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 ser
amplamente adaptável, pois a categoria de produtos por ela compreendida está em
constante evolução: os fornecedores estão constantemente adicionando novas
funcionalidades e identificando novos nichos de produtos (SUN, 2005a). Para
isso, a edição Java ME prevê algumas alternativas de configurações, perfis e
pacotes opcionais para um ambiente de execução Java específico para um
produto.
41
Figura 9 – Arquiteturas de plataformas JAVA.
O CLDC (Connected Limited Device Configuration) é uma configuração
voltada para telefones celulares e PDAs de pequeno porte. Essa configuração
define um pequeno subconjunto da API fornecida pelo Java SE e compartilhada
com o CDC. O objetivo principal do CLDC é a economia da memória. Para isso o
ambiente de execução não oferece funcionalidades como API de reflexão e o
carregamento de classes pela aplicação. Com essa economia os dispositivos que
implementam tal configuração possuem uma necessidade de memória de apenas
128 KB a 256 KB.
O CDC (Connected Device Configuration) tem como objetivo principal a
compatibilidade com o Java SE e suportar dispositivos com recursos limitados.
Ele suporta a implementação completa da máquina virtual Java incluindo
carregamento de classes e suas classes essenciais. Contudo, para atender ao
requisito de operar sobre plataforma de recursos limitados, o CDC realiza
modificações no Java SE: algumas de suas classes tiveram suas interfaces
modificadas e outras retiradas inteiramente. Dessa forma, o requisito dessa
configuraçã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 perfis
proporciona aos fabricantes uma maior flexibilidade, trazendo diferentes níveis de
42
sofisticação à implementação e possibilitando o suporte a diferentes tipos de
dispositivos com um ambiente de execução Java compatível. São eles:
•
Foundation Profile (FP) – é o perfil mais básico. Possui apenas
bibliotecas básicas como rede e Entrada/Saída (I/O). Esse perfil não
suporta 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 o
FP. Permite a construção de GUIs através de um subconjunto
limitado do AWT (Geary & McClellan, 1997) e também implementa
o modelo de programação Xlet que será visto a seguir; e
•
Personal Profile (PP) – É o perfil CDC mais avançado e engloba o
PBP além de suportar integralmente o AWT e applets (SUN, 1994).
Para o desenvolvimento de um ambiente de execução Java em uma edição
Java 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 foi
escolhida a configuração CDC, o perfil PBP, mais o pacote opcional JSSE (Java
Secure 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ção
CDC, 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 o
PersonalJava (uma configuração de máquina virtual Java prevista no GEM/MHP
e cuja normalização foi descontinuada sendo substituída pelo CDC/CLDC).
43
No GEM, por se tratar de um ambiente de TV e por ser um acordo de
harmonização, algumas bibliotecas tornaram-se obrigatórias. Dentre elas, a
biblioteca 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 XLET
O modelo de programação Xlet é voltado para aplicações desenvolvidas
para sistemas de TV Digital. Nesse modelo é possível realizar um controle do
ciclo de vida dessas aplicações através de uma interface Java, mostrada na Figura
12, por elas implementada. As diversas entidades envolvidas nesse modelo, e o
protocolo de comunicação entre elas, são mostrados na Figura 11.
Os Xlets, como são conhecidas as aplicações, podem ser lançados
automaticamente, via sinalização, ou iniciados através da navegação pelo controle
remoto dos telespectadores. Eles podem encontrar-se residentes no receptor, ser
extraídos do carrossel de objetos e dados de um fluxo DSM-CC (ISO, 1998), ou
ser obtidos pelo canal de retorno.
44
Figura 11 – Protocolo entre as entidades presentes no modelo e programação Xlet.
O Gerenciador de Aplicações (Application Manager) é a entidade
responsável pelo carregamento e o controle direto do ciclo de vida dos Xlets. Ele
dever ser capaz de interpretar os dados provenientes da AIT (ou seja, localização
da aplicação, classe inicial etc.) para, de acordo com aqueles recebidos, gerenciar
a execução das aplicações. Através de um mecanismo conhecido como caching, o
Gerenciador de Aplicações mantém uma tabela onde monitora as mudanças de
estado e recomeça a execução de Xlets presentes no receptor. O Gerenciador de
Aplicações é parte do sistema e reside no receptor.
No modelo de programação Xlet, as aplicações devem implementar a
interface mostrada na Figura 12. A classe Java que implementar essa interface é a
porta de entrada no aplicativo. Ela possuirá métodos que refletem diretamente os
estados do ciclo de vida de um Xlet.
public interface Xlet {
public void initXlet(XletContext xtx)
throws XletStateChangeException;
public void startXlet()
public void pauseXlet();
public void destroyXlet(boolean unconditional)
}
Figura 12 - Interface do Xlet.
Uma aplicação Xlet poderá encontrar-se nos estados ilustrados pela máquina
de 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 no
estado Loaded (carregada). O estado Loaded significa que a aplicação já foi
carregada, mas ainda não foi iniciada. No momento seguinte o Gerenciador de
Aplicaçõ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ção
no estado Paused está minimizando o uso de recursos para maximizar sua
sobrevivência, e está pronta para executar. No estado Active, a aplicação está
funcionando plenamente, e no estado Destroyed já liberou todos os recursos e
terminou sua execução.
45
Figura 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 ou
XletContext. Todo Xlet possui um contexto associado, ou seja, uma instância da
classe javax.tv.xlet.XletContext. Isso é similar à classe AppletContext que é
associada a um applet.
O XletContext é uma interface Java (mostrada na Figura 14) cuja
implementação é fornecida pelo Gerenciador de Aplicações. Através dessa
interface, o Gerenciador de Aplicações pode controlar o estado de um Xlet, tendo
a capacidade de encerrar sua execução a qualquer momento. O Xlet pode, ainda,
utilizar o XletContext para acessar propriedades do receptor ou realizar uma
mudanç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 novo
estado desejado ao Contexto. A partir daí, o Gerenciador de Aplicações é
notificado e, em seguida, realiza a mudança do estado do Xlet. Utilizando esse
mecanismo de callback, o Gerenciador de Aplicações pode manter atualizado o
status dos Xlets por ele controlados. Portanto, o Contexto é uma ponte de
comunicação entre o Xlet e o Gerenciador de Aplicações.
46
Os métodos “notifyDestroyed” e “notifyPaused” permitem ao Xlet notificar
o terminal sobre a possibilidade de terminá-lo ou pausá-lo. O Xlet pode usar esses
métodos para ter certeza que o terminal sabe o estado de toda aplicação e pode
tomar a ação apropriada. Esses métodos devem ser chamados imediatamente
antes do Xlet entrar nos estados de Paused ou Destroyed, isto porque o terminal
pode 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 Started
usando o método “resumeRequest”. Isso acontece quando um determinado evento
occorreu, como, por exemplo, um tempo certo foi atingido, um evento certo foi
detectado num fluxo MPEG, etc. Com esse método, é possível reiniciar uma
aplicação após esta ter sido suspensa.
3
Trabalhos Relacionados
As propostas para ambientes de apresentação declarativos compatíveis com
sistemas que implementem o GEM são relativamente recentes. A própria
especificação MHP, como já mencionado, em sua primeira versão não previa um
ambiente dessa natureza, assim como o padrão OCAP que até hoje não o prevê.
As linguagens declarativas adotadas pela maioria dos padrões internacionais
são baseadas no XHTML. Neste capítulo será mostrada uma proposta de um
sistema escrito na linguagem procedural DVB-J e que permite a apresentação de
documentos XHTML.
Dadas as limitações impostas pela linguagem XHTML, discutidas no
Apêndice C, surgiram na Europa duas propostas para a implementação de um
ambiente declarativo, para sistemas que implementam o GEM, utilizando a
linguagem SMIL (W3C, 2005). Uma delas trata de uma implementação realizada
pelo Laboratório de Multimídia e Software para Telecomunicações da
Universidade de Tecnologia de Helsinki (Lamandon et al, 2003); e a segunda faz
parte de um projeto da Information Society Technologies (IST) buscando
investigar formas de melhorar a interatividade com o usuário por meio do avanço
tecnológico provocado pelo DVB-MHP, internet e MPEG4 (Fuhrhop et al, 2003).
Neste capítulo é apresentado, ainda, o Formatador NCL, isto é, a máquina
de apresentação de documentos especificados na linguagem NCL, que é utilizada
como 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 documentos
XHTML por receptores MHP. A Seção 3.2 apresenta o ambiente declarativo
desenvolvido pela UTH. E, por fim, a Seção 3.3 apresenta o ambiente declarativo
para TV Digital desenvolvido pelo projeto da IST.
48
3.1.
O MHP Processando Documentos XHTML
Dado que o DVB-HTML não se encontra implementado a contento e de
forma a permitir o reaproveitamento do conteúdo presente na Web para
apresentação em sistemas de TV Digital, pesquisadores do Departamento de
Ciência da Computação da Universidade de Bologna propuseram um sistema
capaz de processar conteúdos dessa natureza em receptores MHP (Ferretti et al,
2006).
A proposta consiste em uma arquitetura compreendendo dois componentes
diferentes:
•
um serviço automático de transcodificação, mostrado na Figura 15,
capaz de converter o conteúdo da Web (no formato HTML) para
XHTML e repassá-lo para a difusora (para a inserção no carrossel
DSM-CC); e
•
uma aplicação DVB-J capaz de extrair o conteúdo do carrossel e
exibí-lo.
Figura 15 – Arquitetura da proposta do transcodificador.
A estratégia de transcodificação utilizada consiste em, num primeiro
momento, converter o documento de HTML para XHTML Básico que é mais
facilmente processado por clientes de baixo desempenho. O segundo estágio
consiste em remover do documento XHTML elementos que não podem ser
visualizados na TV, reduzindo o tamanho do documento. E, finalmente, é feito
um processamento dos objetos referenciados (inclusive por elos) por esse
documento de forma a torná-los disponíveis no ambiente do cliente.
49
A proposta realiza ainda algumas adaptações para uma melhor navegação
pelo documento:
•
são eliminadas as barras de rolagem. Assim, caso o documento
utilize uma área maior que a tela do usuário para sua exibição, a
aplicação DVB-J divide o documento em páginas; e
•
é criado um novo frame no topo a direita onde são organizados os
elos presentes no documento.
Dessa forma, quando o usuário utiliza as teclas direcionais para esquerda e
direita navega pelas páginas, e quando utiliza as teclas para cima e para baixo
navega pelos elos.
O sistema foi testado em dois ambientes de simulação (o XletView e o
OpenMHP) e em um ambiente DVB-T real. No entanto, o trabalho não menciona
dados importantes como o tamanho da aplicação DVB-J criada, ou o retardo para
a iniciação da apresentação do documento. É mencionado apenas que o protótipo
reduz efetivamente o tamanho dos documentos HTML convertidos.
3.2.
Ambiente declarativo para TV Digital – UTH
A solução consiste no uso de uma máquina de apresentação de documentos
SMIL sobre uma implementação de um sistema de TV Digital denominado
Otadigi. Esse sistema é baseado no padrão europeu DVB, utilizando para
transmissão o DVB-T e como middleware o MHP. Dada sua configuração de
parâmetros de telecomunicações, como modulação, canal, taxa de codificação e
guard-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 foi
desenvolvida 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ção
restrições impostas pelos requisitos de um sistema de TV digital. Originalmente, a
linguagem 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ões
FTV. Quanto à questão da navegação, foi incluído ainda um novo atributo nos
links para identificar suas características: actionable para links acionados por
50
botões coloridos; e focusable para links que serão acessados pelas teclas de
navegação.
Para o cenário de testes foram criados dois programas diferentes: um
teletexto digital e um programa de futebol. O conteúdo das apresentações foi
acessado por 3 meios diferentes: pelo canal de broadcast, utilizando uma banda de
3Mb/s do sistema Otadigi; por um modem analógico de 56Kb/s; e por uma
combinação dos dois (canal de broadcast para o conteúdo genérico e o modem
para o específico/personalizado).
O tamanho da máquina de apresentação totalizou cerca de 1,4 MB. No
ambiente de testes utilizado isso acarretou um tempo de carregamento (download
para memória local) de 19 segundos e um tempo de iniciação de 7 segundos. Parte
desse 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 do
sistema. O modem foi testado como forma de avaliar a viabilidade de
disponibilizar parte dos recursos necessários à apresentação via um canal de
retorno. No entanto, o uso de tal recurso chegou a gerar um atraso de 100
segundos 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 em
um sistema MHP 1.1 que já prevê tal biblioteca nativamente;
•
se possível, a integração da máquina de apresentação SMIL ao
receptor, para diminuir o tempo de carregamento do player;
•
a criação de métodos para utilização de stream events para
sincronizar a máquina de apresentação SMIL com o fluxo
transmitido.
3.3.
Ambiente declarativo para TV Digital – ICECREAM
ICECREAM visa levar a interatividade com o usuário a um nível mais
avançado. Para isso, foi proposto o uso das tecnologias oferecidas pelo
middleware DVB-MHP, a Internet e o padrão MPEG-4.
51
A 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 do
documento SMIL é feita por um Xlet interpretador que cuida de todo controle de
temporização e leiaute informado no documento. O uso do SMIL se dá de forma a
integrar o vídeo principal com recursos interativos adicionais e personalizados via
um 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 o
serviço em tempo de apresentação. Essa customização do documento ocorre
através da interpretação dos parâmetros presentes na query HTTP da requisição
feita pelo receptor ao provedor de conteúdo. O processo ocorre, basicamente, da
mesma forma como é feito para documentos HTML dinâmicos.
Como referência, é apresentada no projeto a implementação de um
programa que mostra uma orquestra em um concerto de música clássica. A
interatividade ocorre através da criação de um documento SMIL que possibilita o
fornecimento de informações sobre o compositor da obra, o condutor da orquestra
e a sala do concerto (programação, compra de ingresso). A personalização neste
caso é feita, por exemplo, através do oferecimento de informações de
programação de casas de concerto na região geográfica específica do
telespectador.
No projeto não são apresentados dados referentes ao desempenho do
sistema proposto.
4
O Fomatador NCL
O Formatador NCL compõe a máquina de apresentação de documentos
NCL. Ele é o elemento responsável por receber a especificação de um
hiperdocumento (sua estrutura, seus relacionamentos e a descrição da forma de
exibição desejada) e concretizá-la na apresentação propriamente dita (Rodrigues,
2003).
No entanto, a implementação Java do Formatador NCL é voltada para a
plataforma Java SE. Para que essa implementação possa executar com o
comportamento esperado em sistemas de TV digital, são necessárias algumas
adaptaçõ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. A
Seção 4.2 sugere uma otimização no método utilizado pelo Formatador para
leitura e conversão do documento NCL. A Seção 4.3 sugere o desmembramento
do Formatador em componentes de software. E, por fim, a Seção 4.4 sugere
algumas mudanças nos em cada módulo do formatador.
4.1.
O Formatador NCL Java
A implementação Java atual do Formatador pode ser estruturada em
módulos como mostrado na Figura 16. Para realizar suas tarefas, tal
implementação conta com o auxílio do conversor, do escalonador e informações
sobre o contexto de execução. Além dessas entidades, o Formatador faz uso dos
serviços oferecidos por mais três elementos: o Gerenciador de Leiaute, o
Gerenciador de Documentos e o Gerenciador de Adaptadores para Exibidores.
O Fomatador NCL
53
Figura 16 – Arquitetura do Formatador NCL.
O processo de apresentação se inicia quando o Formatador recebe um
comando de edição específico para iniciar a apresentação de um documento. A
partir desse comando, o Formatador requisita os serviços do Gerenciador de
Documentos.
O Gerenciador de Documentos tem a responsabilidade de processar os
comandos de edição delegados pelo Formatador e realizar a manutenção dos
documentos NCL ativos em uma base de documentos. Ao receber um comando
de 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, entre
outras); ou, caso o comando de edição contenha especificações XML (por
exemplo, 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ções
XML em entidades do modelo conceitual NCM. São essas entidades que poderão
ser, efetivamente, armazenadas na base de documentos pelo Gerenciador de
Documentos.
As entidades inseridas na base de documentos estão aptas a serem
apresentadas. Para iniciar esse processo, no entanto, é preciso convertê-las para o
O Fomatador NCL
54
modelo de execução interno do Formatador. Isso é feito através do Conversor do
Modelo de Execução.
Essa segunda conversão é realizada sob demanda. O critério utilizado é a
distâ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ância
serão compilados. Cabe ressaltar que essa distância é um dos parâmetros de
configuraçã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 notifica
tal entidade. A partir daí, o Escalonador se cadastra como observador de tais elos
para 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ção
por ele representada.
O Formatador tem, ainda, a responsabilidade de emitir notificações quando
novos objetos de execução são adicionados ao seu modelo de execução. Cada
objeto de execução representa a instância de um nó a ser exibido, especificado no
documento NCL, contendo todas as suas informações, inclusive as suas
características de apresentação provenientes do descritor de apresentação
associado. 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 resolvidas
estaticamente. 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 de
execução adequado.
Mais adiante, no momento em que o Escalonador requisita a execução de
um objeto de mídia, ocorre a interação de mais um módulo do Formatador: o
Gerenciador de Adaptadores para Exibidores. Esse gerenciador tem à sua
disposição um conjunto de adaptadores para os exibidores que tratam
determinados tipos de conteúdo suportados pelo ambiente do Formatador NCL. A
partir do objeto de execução, o gerenciador seleciona o adaptador de um exibidor
capaz de reproduzir o conteúdo de tal objeto.
O Fomatador NCL
55
Como exemplo de exibidores pode-se citar: XHTML, LUA, imagens
estáticas (JPEG, PNG, GIF), áudio (WAVE, MPEG-1, MPEG-2) e vídeo (MPEG1, MPEG-2).
4.2.
O GEM processando um documento NCL
Como visto na Seção 4.1, o primeiro passo para a execução de um
documento NCL é a sua conversão de uma especificação XML para objetos Java
NCL. Essa operação consome tempo, processamento e espaço no receptor para
armazenar uma biblioteca que realize a tradução do documento XML. Esses
requisitos levam à elaboração de dois cenários diferentes para tratar o processo de
conversã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. Nesse
caso, ao invés de receber documentos NCL, os receptores processariam
diretamente objetos Java serializados2, tornando opcional a presença de uma
biblioteca capaz de processar documentos XML. Esse cenário é mais indicado na
presença de um receptor com recursos de processamento/memória bastante
escassos. Contudo, os receptores que se basearem nesse modelo perderão a
capacidade de processar diretamente documentos NCL. Eles não seriam capazes
de atuar em cenários onde lhes fosse exigido, por exemplo, processar documentos
NCL dinâmicos presentes na WEB via canal de retorno. Sua capacidade de
processamento 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 e
enviado para o carrossel de objetos para, em seguida, ser desserializado e
processado pelos receptores.
2
A serialização de objetos JAVA permite a codificação de um objeto e de todos os objetos
por ele referenciados direta ou indiretamente em um fluxo de bytes. Permite ainda a reconstrução
do “grafo” de objetos a partir de um fluxo. Este fluxo possibilita o envio por rede e o
armazenamento em arquivos, por exemplo.
O Fomatador NCL
56
Figura 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 de
processamento/armazenamento e permite o processamento de documentos NCL
em seu estado bruto. A Figura 18 ilustra esse processo em que o documento é
enviado para o carrossel de objetos sendo convertido apenas no ambiente dos
receptores.
Figura 18 – Processamento do documento NCL no receptor
Essa é a forma convencional de operação do Formatador NCL. Ela requer,
da parte do receptor, a presença de uma biblioteca para o processamento de
arquivos XML.
O Fomatador NCL
57
4.3.
A Arquitetura de Implantação
Na Seção 4.1 foi mostrado o caráter modular da arquitetura do Formatador
NCL. Essa característica possibilita a realização de otimizações em seu processo
de implantação. Os seguintes módulos podem ser identificados:
•
Núcleo do Formatador, formado pelo Formatador e compreendendo
o Escalonador, o Conversor e as Informações do Contexto;
•
Gerenciador de Leiaute;
•
Gerenciador de Documentos; e
•
Gerenciador de Adaptadores para Exibidores. Sendo que cada
exibidor por ele gerenciado constitui um módulo específico.
Cada módulo abrange um componente de software diferente. Esses
componentes serão enviados para os receptores para a reprodução do documento
NCL. Contudo, apenas os módulos necessários em um dado cenário deverão ser
carregados.
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 localmente
os módulos comumente utilizados. No entanto, algum mecanismo de controle de
versão torna-se necessário, afim de evitar problemas de compatibilidade e suporte
a atualizações dos módulos.
4.3.1.
Estrutura do Sistema Baseada em Componentes
Ao modelar o Formatador NCL de forma a baseá-lo em componentes de
software, estes devem compor unidades binárias desenvolvidas de forma
independente 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 forma
independente;
•
Fácil manutenção e customização desses componentes para oferecer
novas funcionalidades e recursos. Ou seja, alguns componentes
O Fomatador NCL
58
podem 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 ser
necessariamente a mesma.
No entanto, em sistemas GEM não se pode tirar proveito de todas as
vantagens citadas. Seu ambiente, por exemplo, permite apenas uma linguagem de
programação. Além disso, devido ao fato do programa ter como requisito a
necessidade de operar em uma plataforma com recursos limitados, nenhum
framework/infra-estrutura de componentes (como, por exemplo, CORBA CCM)
deve ser utilizado para a implementação dos mesmos. Porém, é válido para a
elaboração do sistema o uso dos conceitos de componentes independentes de
infra-estruturas comerciais adotadas (Brown & Wallnau, 1999), tornando possível
uma futura adoção de tais infra-estruturas, como sugerido na Seção 6.1.
4.4.
Adaptações e Otimizações no Formatador NCL
O primeiro aspecto a levar em consideração na implementação do
Formatador NCL Xlet é que este deve utilizar apenas as bibliotecas fornecidas
pelo JVM mínimo necessário para o GEM, ou seja, portar o código escrito para
uma 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 cada
componente.
4.4.1.
A Pré-conversão de Documentos NCL e o Módulo Gerenciador de
Documentos
O conversor de documentos NCL está contido dentro do módulo
Gerenciador de Documentos. Ele é responsável por converter os documentos
NCL (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
59
transmissão e, conseqüentemente, ocasiona um maior retardo na iniciação da
apresentação.
A solução proposta na Seção 4.2 prevê a criação de um ambiente de préconversão de documentos NCL. No entanto, de forma a não alterar a interface
fornecida pelo Componente Gerenciador de Documentos e, ainda assim, permitir
a 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ção
são convertidos e adicionados à sua base de documentos. Ao final do processo, o
componente é serializado e enviado aos receptores. Dessa forma, elimina-se a
necessidade do envio da biblioteca XML para o receptor tornando, porém, o
Gerenciador de Documentos incapaz de processar comandos de edição NCL que
necessitem da conversão de especificações XML.
Esse cenário leva à criação de um padrão de apresentação de Documentos
NCL Orientados a Sincronização por Contexto. Nesse padrão, o produtor de
conteúdo criará vários contextos (composições ou documentos) que serão préconvertidos e enviados para os receptores no componente Gerenciador de
Documentos serializado antes do início da apresentação. No momento desejado, a
emissora enviará um comando de edição para a iniciação do contexto. É
importante notar que os documentos desse padrão caracterizam-se por possuir
vários contextos sem elos definidos entre eles.
O exemplo mostrado na Figura 19 ilustra a transmissão de uma partida de
futebol seguindo o padrão de apresentação de Documentos NCL Orientados a
Sincronização por Contexto. Primeiramente, é enviado o Gerenciador de
Documentos juntamente com todos os contextos envolvidos na apresentação da
partida de futebol (no caso, os dois documentos com os identificadores “Futebol”
e “intervalo”). A seguir, é enviado um comando de edição NCL do tipo
startDocument para iniciar a exibição do documento “Futebol”. Durante o jogo é
enviado o mesmo comando no momento em que ocorre o gol de alguma das
equipes, iniciando a exibição de um contexto responsável por mostrar uma
animação comemorativa. Ao longo do jogo, podem ser enviados outros comandos
e 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 a
apresentação do intervalo de jogo.
O Fomatador NCL
60
Figura 19 – Modelo de uma apresentação NCL orientada a sincronização por contexto.
Quando não houver a necessidade de pré-conversão, o componente
Gerenciador de Documentos poderá ser instanciado no receptor. Este é o caso, por
exemplo, de receptores que já possuam nativamente uma biblioteca para a
tradução de documentos XML, ou, ainda, sistemas que possibilitem a persistência
de dados.
4.4.2.
Adaptações do Módulo do Núcleo do Formatador
A porta de entrada para este componente é a entidade que implementa a
interface IFormatter. Atualmente, essa interface encontra-se especificada de
acordo 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 de
um documento a partir de uma âncora), stopDocument (finalizar a
apresentação de um documento), pauseDocument (pausar a
apresentação de um documento) resumeDocument (continuar a
apresentação de um documento);
O Fomatador NCL
61
Realizar a conversão de um documento (através do método
•
compileDocument) para a estrutura de execução interna do
Formatador. Como já mencionado na Seção 4.1, essa conversão é
feita de acordo com uma profundidade definida pelo método
setDepth; e
Processar os comandos de edição (que são tratados pelos métodos
•
abaixo do método resumeDocument na Figura 20 e, em seguida,
enviados para o Gerenciador de documentos).
Essa interface, no entanto, apresenta-se fortemente acoplada ao
componente Gerenciador de Documentos. De forma a diminuir o acoplamento
mencionado, foram realizadas as seguintes adaptações:
•
Os eventos de edição passaram a ser enviados diretamente para o
componente Gerenciador de Documentos;
•
Foi criada uma interface do tipo Listener (de acordo com o padrão
de desenho “Observador”) (Gamma, 2002), permitindo ao
Gerenciador de Documentos a emissão de notificações na
ocorrência de um evento de edição bem sucedido;
•
Foram retirados os métodos que representam os comandos de
edição da interface IFormatter.
62
O Fomatador NCL
Figura 20 – Digrama de classe da interface IFormatter.
Assim, caso o Núcleo do Formatador ofereça suporte a eventos de edição
basta que, internamente, alguma entidade implemente a interface representada no
digrama da Figura 21 e se cadastre como Listener do Gerenciador de
Documentos. No momento que um documento for alterado por um comando de
edição todos os Listeners serão notificados.
O Fomatador NCL
63
Figura 21 – Diagrama da interface NCLEditingCommandListener.
4.4.3.
Adaptações do Módulo Gerenciador de Adaptadores para Exibidores
e os Adaptadores Criados
A adaptação necessária a este componente se dá ao definir a forma como a
classe que implementa a interface IFormatterPlayerAdapter obtém a instância do
adaptador do exibidor. Sempre que for requisitado um adaptador ao gerenciador,
este verifica sua existência no receptor. Caso não logre sucesso, o gerenciador
tentará realizar o carregamento do exibidor necessário para a apresentação através
do IGingaXletDeployer que é detalhado na Seção 5.2.2. Essa interface abstrai do
O Fomatador NCL
64
Gerenciador de Adaptadores a localização e o protocolo para a obtenção do
adaptador.
Os adaptadores criados para a validação da implementação foram o de
texto, o de imagens estáticas e o NCLet. Esse último, em especial, é responsável
por realizar a ponte com o ambiente procedural. O conteúdo de sua exibição são
programas descritos em código binário Java.
4.4.4.
Adaptações do Módulo Gerenciador de Leiaute
No modelo utilizado pelo Formatador NCL, a construção da interface
grá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: o
IFormatterLayout que, de fato, gerencia o leiaute; e o IFormatterRegion que
conté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, introduzido
pelo Formatador, apresentando uma modificação: a adição do método
createRegion na interface IFormatterLayout. Dessa forma, as regiões serão
criadas apenas a partir de seu gerenciador, permitindo que este mantenha uma
referência para todas aquelas criadas.
Diferente do ambiente do desktop, o perfil PBP da configuração CDC não
oferece suporte à biblioteca gráfica SWING (Robinson & Vorobiev, 2003),
apenas AWT (Geary & McClellan, 1997). Nesse perfil, é permitida apenas a
criação de uma única janela (Frame). Com isso, a implementação da classe
IFormatterRegion, responsável por criar os elementos de interface gráfica, foi
alterada para atender tais requisitos.
O Fomatador NCL
Figura 22 – Diagrama de classes do modelo de leiaute do Formatador NCL.
65
5
O Fomatador NCL Xlet
Atualmente, o Formatador NCL encontra-se implementado em duas
linguagens: JAVA e C++. Com o GEM oferecendo um ambiente JAVA para a
execução global de aplicações interativas, tem-se a possibilidade de portar a
implementação do Formatador para sistemas que implementem tal framework.
No entanto, a implementação Java do Formatador NCL é voltada para a
plataforma Java SE. Para que ela possa executar com o comportamento esperado
em sistemas de TV digital, são necessárias algumas adaptações e otimizações a
serem discutidas neste capítulo.
Para cumprir seus propósitos este capítulo está organizado da forma a
seguir. A Seção 5.1 detalha como desmembrar a arquitetura do Formatador em
componentes independentes e as possíveis otimizações que podem ser realizadas
nessa arquitetura. A Seção 5.2 trata da implementação do ambiente a partir das
propostas das seções anteriores e descreve o processo de implantação
(deployment) do sistema proposto nesta dissertação. Ao final da seção, são
apresentados mecanismos para a integração desse mesmo sistema com o padrão
MHP. E, por fim, a Seção 5.3 apresenta o ambiente onde foram realizados os
testes da implementação.
5.1.
Os Componentes do Formatador NCL Xlet
Nas seções a seguir serão descritos os componentes que compõem o
Formatador NCL.
67
5.1.1.
Gerenciador de Leiaute
Figura 23 – Duas implementações do componente Gerenciador de Leiaute
Esse componente é responsável por controlar a interface gráfica do
Formatador. Ele possui a capacidade de criar as regiões onde serão exibidos os
objetos de mídia. Por esse motivo ele deve sofrer uma customização para cada
ambiente gráfico (como X Window System) (Scheifler & Gettys, 1996) no qual
tais objetos serão exibidos.
A interface fornecida por esse componente é a IFormatterLayout, descrita
na Seção 4.4.4, e as interfaces necessárias para sua execução irão depender da
implementação. A Figura 23 ilustra duas implementações diferentes desse
componente: uma para desktops e outra customizada para TV. Na implementação
para TV percebe-se a necessidade da interface IGingaXletConfiguration. Maiores
detalhes sobre essa interface e essa implementação são encontrados na Seção
4.4.4.
Esse componente não é obrigatório. Apesar de na maioria das vezes haver a
necessidade de seu uso, em apresentações onde for necessário apenas o
sincronismo entre objetos de mídia do tipo áudio, não há a necessidade do
carregamento desse componente.
68
5.1.2.
Gerenciador de Documentos
Figura 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 da
base. Dentre outras coisas, o componente Gerenciador de Documentos é capaz de
receber a especificação de documentos XML, verificar se estes possuem uma
sintaxe/semântica NCL válida e convertê-los para objetos Java. Para realizar esse
processo, o componente necessita da presença de uma biblioteca capaz de
processar documentos XML. Basicamente, o componente é formado pelas
seguintes entidades, mostradas na Figura 16: Gerenciador de Documentos,
Conversor NCL e a Base de Documentos.
O recebimento de documentos XML é feito através da interface
INCLDocumentManager, mostrada na Figura 24. O conjunto de métodos
providos por essa interface permitem ao componente processar os Comandos de
Edição NCL.
A necessidade desse componente vai depender da implementação do
componente do Núcleo do Formatador. Uma implementação mais simples de
núcleo que, por exemplo, processe apenas um documento (incluindo os
documentos por ele referenciados) por vez e não dê suporte a eventos de edição
NCL não necessitaria desse componente.
69
5.1.3.
Núcleo do Formatador
Figura 25 – Duas implementações do componente do núcleo do formatador.
Dos componentes apresentados esse é o mais importante e obrigatório. Ele
será o responsável por controlar a apresentação e corresponde diretamente ao
núcleo do Formatador mostrado na Seção 3.4.
Esse componente pode ter sua implementação customizada de forma a
simplificar o seu funcionamento. Como mostrado na Figura 25, pode-se criar uma
implementação simples de Núcleo independente do Gerenciador de Documentos.
Esse componente depende ainda das interfaces IFormatterLayout (oferecida pelo
Gerenciador de Leiaute) e IPlayerAdapterManager (oferecida pelo Gerenciador
de 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 interface
IFormatter possui a assinatura mostrada na Figura 26.
Figura 26 – Duas implementações do componente do núcleo do formatador
70
5.1.4.
Gerenciador de Adaptador para Exibidores
Figura 27 – Duas implementações do componente Gerenciador de Exibidores
Esse componente é obrigatório para a execução do Formatador NCL. A
gestão realizada por ele compreende a identificação e instanciação do adaptador
para o exibidor necessário para a apresentação de um determinado tipo de
conteúdo.
Assim como o Gerenciador de Leiaute, esse componente apresenta uma
forte dependência com o ambiente no qual será executado (TV, Desktop). Isso
porque, além de, no caso de exibidores de vídeo ou imagens, haver uma
dependência quanto à interface gráfica do ambiente, a forma como são obtidos os
recursos (no caso, os exibidores) depende do ambiente de execução. Num sistema
de TV Digital, por exemplo, os recursos podem estar presentes no carrossel de
objetos DSM-CC, sistema de arquivos local ou canal de retorno. O mecanismo
utilizado para identificação de recursos num sistema GEM é tratado na Seção 4.3.
5.1.5.
Adaptadores para Exibidores
Figura 28 – Duas implementações de adaptadores para exibidores.
71
Esse componente constitui uma camada de adaptação para exibidores de um
determinado tipo de conteúdo de forma a torná-los compatíveis com o modelo de
execução do Formatador NCL. Existe uma implementação diferente desse
componente para cada exibidor suportado pelo formatador.
Na apresentação de um dado documento NCL nem todos os exibidores
disponíveis para o Formatador NCL são necessariamente utilizados. Existem, por
exemplo, apresentações que envolvem apenas imagens estáticas, outras apenas
textos. Dessa forma, a obrigatoriedade desse componente depende do tipo de
conteúdo por ele processado e a presença desse conteúdo na apresentação.
Para tornar esse componente independente do protocolo utilizado para a
obtenção do conteúdo a ser exibido, utiliza-se as facilidades oferecidas pela
interface IGingaXletDeployer para o carregamento de arquivos. Isso porque, por
exemplo, antes de obter um arquivo de um carrossel DSM-CC, é necessário
estabelecer uma conexão. A interface IGingaXletDeployer abstrai todas essas
peculiaridades. Mais informações sobre o funcionamento dessa classe podem ser
encontradas na Seção 5.2.2 e 5.2.3.
5.2.
Implementação dos Componentes para Sistemas GEM
Esta seção e suas subseções descrevem a implementação do ambiente de
execução declarativo, baseado na linguagem NCL. Esta implementação é baseada
na implementação Java do Formatador NCL. A partir dela são feitas adaptações
para 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 do
Formatador NCL Xlet é que este deve utilizar apenas as bibliotecas fornecidas
pelo JVM mínimo necessário para o GEM, ou seja, portar o código escrito para
uma 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 cada
componente.
72
5.2.1.
O Carregamento Dinâmico
A chave para a criação de uma arquitetura modular, onde os módulos
podem ser carregados dinamicamente no decorrer da execução da aplicação, é o
uso
das
tecnologias
oferecidas
pelas
classes
java.lang.Class
e
java.lang.ClassLoader.
Cada classe Java disponível para uso por uma aplicação é carregada por um
objeto ClassLoader a ela associado. Ou seja, quando o Gerenciador de
Aplicações, abordado na Seção 2.4, inicia a execução do Xlet, todas as classes
disponíveis para uso por este Xlet estão associadas a um ClassLoader uilizado
para 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 novas
classes que antes não se encontravam disponíveis para o uso pela aplicação. A
este 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 classes
presentes no ambiente de execução da aplicação. É possível carregar classes
disponíveis em ambientes remotos através da transferência do código binário
destas classes via protocolos de rede. A classe java.net.URLClassLoader
utiliza, por exemplo, uma conexão baseada no protocolo especificado via URL
(desde que implementado pelo ambiente de execução Java local) para transferir e
carregar o código binário das classes. O carregamento dinâmico ainda traz um
benefí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 do
sistema. Isso porque a classe só é carregada quando requisitado e não na
inicialização do sistema.
A partir do momento em que a classe encontra-se disponível para uso, por
não possuir uma referência estática, seu referenciamento e instanciação deverão
ocorrer de forma dinâmica, ou seja, para obter uma referência para a nova classe
utiliza-se o método estático “forName” da classe java.lang.Class passando
como parâmetro o nome da classe a ser instanciada. Este método retornará uma
instância da classe java.lang.Class. Com esse objeto pode-se, finalmente,
73
criar uma instância da classe (dinamicamente carregada) através do método
“newInstance”.
No sistema proposto foi criada uma entidade que se responsabiliza pelo
carregamento dinâmico dos módulos do formatador e a extração de tais módulos
do fluxo MPEG-2: o GingaXletDeployer.
5.2.2.
O Módulo de Implantação
Esse módulo é responsável por realizar a implantação do ambiente
declarativo. A implementação desse módulo vai depender da plataforma para a
qual o ambiente declarativo se destina. Pode oferecer, inclusive, mecanismos
sofisticados de implantação/monitoramento dos componentes. No entanto, no
caso de sistemas GEM sua implementação deve ser simplificada.
Para a implementação desse componente foram criadas quatro classes:
GingaXlet,
IGingaXletConfiguration,
IGingaXletDeployer
e
StreamEventHandler.
Figura 29 – Classe GingaXlet.
A classe GingaXlet, mostrada na Figura 29, é a implementação da interface
Xlet necessária para o modelo de programação do Java TV. Essa classe é o ponto
de entrada da aplicação e, através dela, o Gerenciador de Aplicações do receptor
controlará o ciclo de vida da aplicação. A assinatura dessa classe é idêntica a de
um Xlet mostrada na Figura 9 na Seção 2.4. A classe GingaXlet possui referência
para todos os componentes instanciados no sistema e para a entidade
StreamEventHandler, que será apresentada a seguir. A utilidade desses atributos
será apresentada na Seção 5.2.3.
74
Figura 30 – Classe IGingaXletConfiguration.
A classe que implementa a interface IGingaXletConfiguration, mostrada na
Figura 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 de
Aplicações, fornecidos na inicialização da aplicação via sinalização ou presentes
em arquivos de configuração. Existem dois parâmetros importantes fixados pela
IGingaXletConfiguration, são eles: a localização das bibliotecas disponíveis, ou
seja, 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 comando
de edição NCL.
A instanciação dessa classe ocorre no momento de iniciação (chamada ao
método “initXlet”) do Xlet. Isso porque essa classe deve acessar o contexto do
Xlet para ter acesso às suas propriedades.
Figura 31 – Interface IGingaXletDeployer.
A classe que implementa a interface IGingaXletDeployer, mostrada na
Figura 31, é responsável pela implantação do Formatador. O processo todo é
realizado quando chamado o método deployFormatter. Esse método esconde toda
a lógica de localização dos componentes (que podem apresentar-se no fluxo
MPEG-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. Mais
detalhes sobre o funcionamento desse método são fornecidos na Seção 5.3. Em
contrapartida, seu método undeployFormatter é responsável por realizar a
75
finalização dos componentes permitindo, caso o ambiente permita, o
armazenamento 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 biblioteca
JAVA;
•
O carregamento de arquivos a partir de uma URL de localização do
arquivo;
•
E o pré-carregamento de arquivos a partir de uma URL de
localização do arquivo.
A classe StreamEventHandler é responsável por tratar os eventos DSM-CC
enviados no fluxo MPEG-2. Sua assinatura, mostrada na Figura 32, é herdada da
interface
org.dvb.dsmcc.StreamEventListener
descrita
na
especificaçã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. Esse
tratamento envolve o envio dos Comandos de Edição NCL para o componente
Gerenciador de Documentos ou a alteração do estado da apresentação do
Formatador. Dessa forma, essa classe possuirá uma referência para o Componente
Gerenciador 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 de
Objetos.
Esse
objeto
de
eventos
é
obtido
através
da
interface
IGingaXletConfiguration. Ao se cadastrar nesse objeto, a classe será notificada à
medida que os eventos DSM-CC aparecerem no fluxo MPEG-2.
76
5.2.3.
O Processo de Implantação do Formatador
A seguir será descrito o processo de implantação do formatador partindo do produtor
de conteúdo.
5.2.3.1.
O Produtor
O produtor de conteúdo será responsável por enviar os componentes e os
documentos para a apresentação. Para isso, o produtor deverá sinalizar, via AIT, a
localização no Carrossel DSM-CC
dos componentes de software e dos
documentos e mídias envolvidas na apresentação.
Caso seja adotada a estratégia de pré-conversão do documento NCL
produtor deverá instanciar o Componente Gerenciador de Documentos, adicionar
os documentos necessários para a apresentação e adicionar este novo objeto Java
serializado no mesmo diretório onde se localizarão os componentes.
5.2.3.2.
O Receptor
O processo de implantação do Formatador Xlet inicia-se quando sua
presenç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 dos
exibidores e do Stream Event Object através do qual serão recebidos os eventos
de edição.
Depois de recebida a sinalização, o Gerenciador de Aplicações assume o
controle 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 de
configuração utilizados pela aplicação, dentre eles os argumentos passados para a
77
aplicação (como o Localizador das bibliotecas e o Localizador do objeto de
eventos que conterá os eventos para a identificação de recursos exposta na Seção
4.3 e demais eventos de edição NCL).
Após a criação da entidade de configuração, é instanciada a entidade de
implantação do Formatador denominada GingaDeployer (classe que implementa a
interface IGingaXletDeployer). Essa entidade, como já mencionado, está
diretamente ligada à versão do Formatador a ser implantada. Ela fará o
carregamento de cada componente realizando sua instanciação e resolvendo suas
dependências.
Feita a implantação do Formatador, o GingaDeployer passará o controle
desta entidade ao GingaXlet. Assim, qualquer alteração no estado da aplicação
(Xlet) poderá ser refletido no estado da apresentação do Formatador via
GingaXlet, ou seja, no momento em que os métodos pauseXlet ou destroyXlet
dessa 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. A
essa classe serão passadas as referências para o Componente Gerenciador de
Documentos e o Componente do Núcleo do Formatador.
No método startXlet
da classe GingaXlet, seu atributo que contém a
referência para o StreamEventHandler se cadastrará em um objeto de eventos
DSM-CC (fornecido pelo IGingaXletConfiguration). Esse objeto é representado
pela
classe
DSMCCStreamEvent
do
MHP.
Após
o
cadastro,
o
78
StreamEventhandler receberá os comandos de edição e repassará para os
Componentes 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 apenas
pausada) e o StreamEventHandler é descadastrado do objeto de Eventos DSM-CC
deixando de receber os comandos de edição.
No método destroyXlet ocorre o mesmo procedimento do método pauseXlet, no
entanto, é o método undeployFormatter da classe GingaXletDeployer é chamado para
finalizar os componentes.
5.2.4.
Persistência do Formatador NCL Xlet em Receptores MHP
A implementação do Formatador NCL para sistemas GEM proposta nesse
trabalho se adapta facilmente tanto ao mecanismo de plug-ins como ao
armazenamento de aplicações, mostrados no Capítulo 3, sem grandes
modificações.
No caso do mecanismo de plug-ins, a implementação da interface
org.dvb.application.plugins.Plugin
torna-se trivial, sendo necessário
apenas instanciar a implementação da classe GingaXlet e retorná-la no método
initApplication. Dessa forma, o sistema agirá, na presença de um documento
NCL, como se possuísse nativamente a capacidade de interpretá-lo.
No caso da utilização do mecanismo de Application Storage, são grandes as
vantagens apresentadas. Nenhum esforço precisa ser feito em termos de
implementação. A diferença das aplicações que utilizam esse mecanismo está
apenas no processo de sinalização.
79
Um fator restritivo na utilização desses dois mecanismos é que eles devem
ser utilizados isoladamente em uma rede de comunicação, ou seja, na
apresentação de um programa deverá ser utilizado apenas um dos tipos de
sinalização possíveis para a execução do Formatador NCL: o convencional que
trata o Formatador como um aplicação Java; a sinalização de um documento
NCL como uma aplicação a ser executada pelo plug-in; ou a sinalização para
execução de uma aplicação armazenada.
5.3.
Testes
Para a validação do sistema criado nesta dissertação foi criado um ambiente
de testes utilizando a configuração de máquina virtual CDC (SUN, 2005b)
oferecida pela SUN juntamente com o perfil PBP. Foi utilizada, ainda, uma
implementação do middleware MHP aberta conhecida como OpenMHP (Tucs &
Axel, 2005). Nesse middleware foram realizadas adaptações de forma a melhor
refletir um ambiente de TV Digital. A plataforma escolhida foi um sistema Linux
instalado 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.
80
Figura 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
de
“Compile.jar”
corresponde
ao
Gerenciador
de
implantação;
•
O
arquivo
Documentos;
•
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 do
exibidor de imagens estáticas; e
•
O arquivo “TextPlayerAdapter.jar” corresponde ao componetne
exibidor de texto.
Componente
Deployer.jar
Compiler.jar
Ginga.Jar
Diserializer.Jar
ImagePlayerAdapter
TextPlayerAdapter
Total
Tabela 1 – Componentes do formatador GingaXlet
Tamanho
6,5 KB
111 KB
148 KB
1,5 KB
4,4 KB
4,3 KB
275,7 KB
A fim de verificar a viabilidade da serialização do componente Gerenciador
de Documentos, foram realizados testes de desempenho comparando dois
81
cenários: serialização contra a conversão do documento XML. Na serialização o
tempo 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 do
documento XML até a presença da instância do Gerenciador de Documentos
juntamente com o documento convertido. Os arquivos testados fazem parte de um
conjunto de documentos elaborados pelo Laboratório de Telemídia da Puc-Rio
para o teste de conformidade do Ginga-NCL. Para cada arquivo testado foram
realizados 1000 ensaios. Nos testes, os documentos a serem executados foram
adicionados ao Gerenciador de Documentos e este foi serializado. A
implementação utilizada da interface IGingaXletDeployer realiza a implantação
do Formatador através da desserialização do componente Gerenciador de
Documentos 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
connectorBase.ncl
10
15
11
25
29
descriptor01.ncl
26
60
31
47
54
descriptor02.ncl
27
134
33
49
54
descriptor03.ncl
33
60
38
55
67
descriptor04.ncl
33
96
39
56
152
descriptor05.ncl
27
49
30
49
54
descriptor06.ncl
26
42
28
47
53
descriptor07.ncl
30
38
32
53
61
descriptor08.ncl
33
61
35
56
156
descriptor09.ncl
27
33
28
49
55
descriptor10.ncl
27
34
28
49
56
descriptor11.ncl
27
33
28
49
56
descriptor12.ncl
26
43
28
49
55
Structure01.ncl
9
21
10
11
14
Structure02.ncl
9
19
10
11
14
Structure03.ncl
9
19
10
11
18
Structure04.ncl
9
18
10
12
63
Structure05.ncl
9
14
10
11
19
Tabela 2 – Resultados dos testes de Serialização versus conversão
Médio
26
49
50
57
59
50
49
55
59
50
51
50
50
12
12
12
13
12
Os resultados obtidos pelos testes são mostrados na
Documentos
connectorBase.ncl
descriptor01.ncl
descriptor02.ncl
descriptor03.ncl
descriptor04.ncl
descriptor05.ncl
descriptor06.ncl
descriptor07.ncl
descriptor08.ncl
Serialização(ms)
Mínimo Máximo
10
15
26
60
27
134
33
60
33
96
27
49
26
42
30
38
33
61
Médio
11
31
33
38
39
30
28
32
35
Conversão(ms)
Mínimo Máximo
25
29
47
54
49
54
55
67
56
152
49
54
47
53
53
61
56
156
Médio
26
49
50
57
59
50
49
55
59
descriptor09.ncl
descriptor10.ncl
descriptor11.ncl
descriptor12.ncl
Structure01.ncl
Structure02.ncl
Structure03.ncl
Structure04.ncl
Structure05.ncl
82
27
27
27
26
9
9
9
9
9
33
34
33
43
21
19
19
18
14
28
28
28
28
10
10
10
10
10
49
49
49
49
11
11
11
12
11
55
56
56
55
14
14
18
63
19
50
51
50
50
12
12
12
13
12
Tabela 2. Pode-se perceber que: em todos os testes o cenário utilizando a
serialização é, em média, ligeiramente inferior, em se tratando de tempo de
espera; e que os testes não mostraram nenhum indício de que tal cenário não
possa ser adotado.
Outro teste a ser realizado consiste em verificar o tamanho do arquivo NCL
serializado em comparação com o arquivo em sua forma convencional e se o
retardo provocado por essa diferença é definitivamente relevante. No entanto esse
teste será alvo de trabalhos futuros.
6
Conclusões
O objetivo principal deste trabalho foi elaborar um ambiente de execução
declarativo para sistemas que implementem a especificação do GEM. O ambiente
desenvolvido foi baseado na implementação Java do Formatador NCL criada pelo
Laboraório TeleMídia da PUC-Rio e permite que os programas declarativos
produzidos para o Sistema Brasileiro de TV Digital Terrestre sejam apresentados
em qualquer sistema que implemente o framework GEM.
A fim de melhor compreender as tecnologias envolvidas na elaboração
desse ambiente, foram apresentados no Capítulo 2 os middleware para TV Digital
Terrestre que implementam a especificação do GEM e foi feita uma breve
descrição deste padrão.
No Capítulo 3, foram descritos alguns trabalhos relacionados com o tema
proposto nesta dissertação. Foram analisadas duas implementações de ambientes
declarativos para sistemas GEM tendo como base a linguagem SMIL. A partir dos
trabalhos realizados na linguagem SMIL, foi possível compreender a grande
dificuldade encontrada no desenvolvimento de aplicações para sistemas de TV
Digital: o tempo de iniciação. Ou seja, o tempo decorrido desde a recepção do
documento declarativo até sua exibição.
Ao final do Capítulo 3, foi apresentada a implementação Java do
Formatador NCL, que serviu como base para o ambiente proposto nesta
dissertação. Essa implementação foi alterada visando atender à API diferenciada
do 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 de
software, sendo criadas diferentes implementações desses componentes,
atendendo tanto a desktops como sistemas GEM.
Foi desenvolvida uma estratégia diferente de implantação do Formatador
NCL para receptores com recursos de memória limitados. Essa estratégia faz uso
do mecanismo de serialização, oferecido pela linguagem Java, e realiza todo o
processo de conversão do documento NCL em seu distribuidor.
Conclusões
84
Outra otimização (mostrada no Capítulo 4) pode ser realizada para sistemas
DVB-MHP que ofereçam suporte às facilidades de plug-ins interoperáveis e
armazenamento de aplicações. Dessa forma, o ambiente declarativo proposto
poderá 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 o
exibidor SMIL apresentado no Capítulo 3. Em sistemas com suporte à
persistência de dados e de mídia empacotada (como o Blue-Ray Disc) as
otimizações permitem um desempenho ainda maior em termos de tempo de
iniciação.
6.1.
Trabalhos Futuros
Alguns pontos dos trabalhos realizados nesta dissertação podem ser
explorados como trabalhos futuros.
A configuração de máquina virtual CDC e seus perfis possuem
implementações disponíveis para as mais diversas plataformas (mostradas na
Tabela 3). Novos testes em novas plataformas são valiosos para a validação da
implementação proposta nesta dissertação.
Darwin/PowerPC
Linux/ARM
Linux/MIPS
Linux/PowerPC
Linux/Sparc
Linux/x86
Solaris/Sparc
Solaris/x86
Symbian/ARM
Symbian/x86
Vxworks/Sparc
Vxworks/x86
Win32/ARM/PocketPC
Win32/ARM/WindowsMobile5
Win32/MIPS/WindowsCE
Win32/x86
Win32/x86/PocketPC
Tabela 3 – Plataformas que implementam o CDC.
Conclusões
85
Outro aspecto mostrado neste trabalho que pode render trabalhos futuros é a
modelagem do Formatador NCL baseada em componentes. Nem todas as
facilidades proporcionadas por essa modelagem puderam ser aproveitadas neste
trabalho 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, por
exemplo, pode haver uma cooperação entre componentes implementados nessas
diferentes linguagens.
Figura 36 – Arquitetura de execução distribuída do Formatador NCL.
Além disso, pode-se explorar a distribuição desses componentes criando
arquiteturas de execução como a mostrada na Figura 36. Nessa Figura, existe um
componente Gerenciador de Documentos centralizado de onde vários Núcleos de
Formatadores obtêm os documentos NCL a serem apresentados.
Utilizando esse mesmo componente podem existir, ainda, diversas
ferramentas de autoria. Dessa forma seria possibilitada uma autoria colaborativa
de documentos NCL ao vivo.
7
Referências Bibliográficas
ARIB. ARIB STD-B24, Version 3.2, Volume 3: Data Coding and Transmission
Specification for Digital Broadcasting, ARIB Standard, 2002.
ARIB. ARIB STD-B23, Application Execution Engine Platform for Digital
Broadcasting. ARIB Standard, 2004.
ATSC. DTV Application Software Environment Level 1 (DASE-1) PART 1:
Introduction, Architecture, and Common Facilities. ATSC Standard. Março
de 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 de
2005.
BDA, Blue-Ray Disc Format – 2.B Audio Visual Application Format
Specifications 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 Web
and Mobile Devices, Springer, 2004.
BROWN, A. W.; WALLNAU, C. K. International Workshop on ComponentBased Software Engineering. International Conference on Software
Engineering ’99 – Los Angeles. 1999.
ECMA Standardizing Information and Communication Systems. ECMAScript
Language 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)
87
Specification 1.1.1, ETSI TS 102 812, Maio de 2005. Disponível em:
<www.mhp.org/>. 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 International
Conference on World Wide Web, p.899-900, 2006.
FUHRHOP, C.; HU, J.; GAFSOU, O. Prototype of Applications, User Interfaces
and 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 de
1996. Disponível em: <http://java.sun.com/docs/white/langenv/>. Acesso em
15/01/2007.
FILHO, G. L. S. F.;LEITE, L. E. C.; BATISTA, C. E. C. F. Ginga-J: The
Procedural Middleware for the Brazilian Digital TV System. Journal of The
Braziian Computer Society, Março de 2007, p. 47-56.
HAVi Organization, HAVi-Home Audio/Video Interoperability. 1999,
Disponível em: <http://www.havi.org>. 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 and
associated 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 and
hypermedia information -- Part 5: Support for base-level interactive
applications. ISO Standard, 1997.
ISO/IEC 13818-6. Information technology - Generic coding of moving
pictures and associated audio information - Part 6: Extensions for DSMCC. ISO Standard, 1998.
88
ITU-T. Worldwide common core – Application environment for digital
interactive television services. ITU-T J.200. Março de 2001.
ITU-T. Harmonization of procedural content formats for interactive TV
applications. ITU-T J.202. Maio de 2003.
ITU-T. Harmonization of declarative content format for interactive television
applications. ITU-T J.201. Julho de 2004.
LAMANDON, J. L.; CESAR, P.; HERRERO, C.; VUORIMAA, P. “Usages of a
SMIL Player in Digital TV” VII IASTED International Conference on
Internet and Multimedia Systems and Applications, Agosto de 2003, p. 579584.
LARMAN, C., Utilizando UML e Padrões – Uma Introdução à análise e ao
Projeto Orientados a Objetos. Editora Bookman, 2002.
LIANG, S.; BRACHA, G. Dynamic Class Loading in the Java Virtual
Machine. 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:
<http://www.mhp.org/about_mhp/who_is_using_mhp>.
Acesso em: 14/01/2007.
OPENCABLE, Opencable Application Plataform Specification - OCAP 1.0
Profile – OC-SP-OCAP1.0-I16-050803. Issued Specification, Agosto de
2005.
PENG, C.; VUORIMAA, P. Digital Television Application Manager. IEEE
International 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.
89
RODRIGUES, R.F., Formatação e Controle de Apresentações Hipermídia
com Mecanismos de Adaptação Temporal. Tese (Doutorado em
Informática) – PUC-RJ, Rio de Janeiro 2003.
SCHEIFLER, R. W.;GETTYS, J. X Window System: Core and extension
protocols: X version 11, releases 6 and 6.1. Digital Press, 1996.
SCHWALB E. M. iTV Handbook - Technologies and Standards, IMSC Press
Multimedia Series, Prentice Hall PTR, 2004.
SHEPPARD, Bill; MOLL, E. Java Technology Goes to the Movies: Java
Technology in Next-Generation Optical Disc Formats. 2006 JavaOne
Conference, 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. Modelo
de Contexto Aninhados – versão 3.0. Relatório Técnico, Laboratório
Telemí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, PUCRio, Outubro de 2006.
SOARES, L.F.G. et al, Nested Context Language 3.0 Part 9 – NCL Live
Editing Commands. Monografias em Ciências da Computação, PUC-Rio,
Dezembro de 2006.
SOARES, L.F.G.; RODRIGUES, R.F.; Mecanismo de Identificação de
Recursos para Aplicações Interativas em Redes de TV Digital por
Difusão. 25o Simpósio Brasileiro de Redes de Computadores e Sistemas
Distribuídos. Maio de 2007.
SUN
MICROSYSTEMS.
Applets.
1994.
Disponível
em:
<http://java.sun.com/applets>. Acessado em: 15/01/2007.
SUN MICROSYSTEMS. Java Media Framework, v2.0 API Specification.
1999.
Disponível
em:
Acessado em: 15/01/2007.
<http://java.sun.com/products/java-media/jmf/>.
SUN
MICROSYSTEMS.
90
Object
Serialization.
1999.
<http://java.sun.com/j2se/1.3/docs/guide/serialization>.
Disponível
em:
Acessado
em:
17/05/2007.
SUN MICROSYSTEMS. Permissions int the Java 2 SDK. 2002. Disponível
em:
<http://java.sun.com/j2se/1.4.2/docs/guide/security/permissions.html>.
Acessado em: 17/01/2007.
SUN MICROSYSTEMS. CDC: Java Plataform Technology for Connected
Devices. 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: <http://www.openmhp.org>. Acessado em: 15/01/2007.
W3C. Cascading Style Sheets, level 2 - CSS 2 Specification, W3C
Recommendation, 1998.
W3C. HTML 4.01 Specification. W3C Recommendation, Dezembro de 1999.
W3C. XHTML 1.0 The Extensible HyperText Markup Language (Second
Edition) – A Reformulation of HTML 4 in XML 1.0. W3C
Recommendation, Agosto de 2002.
W3C. Document Object Model (DOM) Level 3 Core Specification. W3C
Recommendation, Abril 2004.
W3C. XML Schema Part 0: Primer Second Edition. W3C Recommendation,
Outubro de 2004.
W3C. Synchronized Multimedia Integration Language (SMIL 2.1). W3C
Recommendation, Dezembro de 2005.
WEBER, J. W.; NEWBERRY, T. IPTV Crash Course. McGraw-Hill, 2006.
Apêndice A
Assinatura Digital de um Xlet
A execução de aplicações em receptores de TV digital domésticos permite o
acesso a recursos em tais equipamentos que, no caso de um comprometimento de
sua segurança, podem expor dados sigilosos de seus usuários. Para restringir o
acesso a tais recursos sensíveis do receptor, foram criados mecanismos que
permitissem a sua utilização por aplicações confiáveis.
O uso dos Arquivos de Requisição de Permissão (PRFs) é um mecanismo
criado para permitir o acesso pelas aplicações a certos recursos sensíveis dos
receptores em termos de falhas de segurança. Esses recursos incluem, por
exemplo, acesso ao disco local, às preferências dos usuários, ao uso do canal de
retorno, entre outros. Vale lembrar que o acesso a tais ativos deve ser controlado
devido ao fato de as aplicações não necessariamente localizarem-se apenas no
fluxo de transporte proveniente das difusoras; elas podem ser obtidas também via
canal de retorno por provedores de conteúdo das mais diversas origens.
A especificação do GEM prevê que um receptor que suporte tal framework
seja capaz, no mínimo, de processar os PRFs criados pelo padrão MHP. A Figura
37 ilustra um exemplo de arquivo e configuração que respeita tal padrão. O
arquivo do exemplo permite a leitura das preferências do usuário; o uso do canal
de retorno; bloqueia a sintonização; permite a seleção do serviço; permite a leitura
e escrita de dois arquivos; entre outros.
<?xml version="1.0"?>
<!DOCTYPE permissionrequestfile PUBLIC "-//DVB//DTD Permission
Request File 1.0//EN"
"http://www.dvb.org/mhp/dtd/permissionrequestfile-1-0.dtd">
<permissionrequestfile orgid="0x000023d2" appid="0x4020">
<file value="true"></file>
<applifecyclecontrol value="true"></applifecyclecontrol>
<returnchannel>
<defaultisp></defaultisp>
<phonenumber>+552135211500</phonenumber>
<phonenumber>+552135211501</phonenumber>
<phonenumber></phonenumber>
</returnchannel>
Apêndice A
92
<tuning value="false"></tuning>
<servicesel value="true"></servicesel>
<userpreferences read="true" write="false"></userpreferences>
<network>
<host action="connect">hostname</host>
</network>
<persistentfilecredential>
<grantoridentifier id="0x000023d2"></grantoridentifier>
<expirationdate date="24/12/2032"></expirationdate>
<filename read="true"
write="true">23d2/4020/formatterConfig/context/context.ini</filena
me>
write="true">23d2/4020/formatterConfig/players/mimedefs.ini</filen
ame>
write="true">23d2/4020/formatterConfig/players/ctrldefs.ini</filen
ame>
<signature>023203293292932932921493143929423943294239432
</signature>
<certchainfileid>3</certchainfileid>
</persistentfilecredential>
</permissionrequestfile>
Figura 37 – Exemplo de arquivo PRF.
O arquivo PRF permite ainda a leitura de três arquivos localizados no
dispositivo de armazenamento local no receptor: context.ini, mimedefs.ini e
ctlrdefs.ini.
Os dois diretórios iniciais do caminho de acesso a tais arquivos consistem
do identificador da organização e o identificador da aplicação responsáveis por
realizar sua gravação em disco. Isso é parte de uma padronização proposta pelo
MHP e absorvida pelo GEM que permite a uma aplicação criar arquivos apenas
em diretórios que contenham em seu caminho inicialmente tais identificadores.
Vale ressaltar que é permitido que diferentes organizações/aplicações
acessem um arquivo gravado em disco. Contudo, é necessário apresentar no
arquivo PRF o identificador da organização responsável pela gravação original do
arquivo (através do elemento “grantoridentifier”) e uma assinatura (através do
elemento “signature”). Com isso, o receptor terá garantias que esta nova
aplicação tem permissão de ler/alterar um arquivo que não foi originalmente por
ela criado.
Apêndice A
93
Figura 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 no
exemplo é TestXlet.class e o arquivo PRF é isdtv.TestXlet.perm); e
•
Todos os diretórios que tiverem seu conteúdo assinado possuirão
um arquivo contendo uma assinatura do tipo hash de todo ele
(utilizando o algoritmo MD5, por exemplo). No exemplo da Figura
38, o diretório “data” não tem seu conteúdo assinado.
Apêndice B
Sinalização de Aplicações
O processo de sinalização de aplicações recomendado pelo GEM e
adotado pelo MHP envolve o envio periódico de uma tabela denominada Tabela
de Informação de Aplicações (AIT – Application Information Table). Essas
tabelas constituem um fluxo elementar do fluxo de transporte MPEG-2. Elas são
um tipo de PSI (Program Specific Information). Esse apêndice explica os
principais atributos presentes na AIT e relevantes para a implementação de uma
aplicação DVB-J.
As AITs são identificadas na PMT como um fluxo do tipo 0x05. Além
disso, opcionalmente, a PMT pode conter um descritor de sinalização contendo o
tipo de aplicação e a versão da AIT. Dessa forma, o processo de sinalização fica
otimizado pois, receptores que não possuam capacidade de processar um
determinado tipo de aplicação não necessitam decodificar toda a AIT, e mudanças
na 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, uma
lista com os descritores de informações específicas de cada uma dessas
aplicações, além dos campos tipo da aplicação, os códigos de controle da
aplicaçã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ções
DVB-J.
O campo “versão da tabela” funciona como uma otimização para que
uma 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. O
que significa dizer que através dele a emissora pode mandar comandos para
encerrar uma aplicação, auto iniciar ou apenas informar a sua disponibilidade para
o usuário.
Os “identificadores das aplicações” são um par contendo o identificador
da organização que produziu a aplicação e o identificado da aplicação.
Apêndice B
95
A Tabela 4 mostra os principais campos, citados anteriormente, e seus
respectivos valores a fim de exemplificar uma AIT para o carregamento do
Formatador NCL.
Tipo de Aplicação
0x0001 (DVB-J)
Versão
0x0
Descritores comuns()
for(i=0;i<N;i++){
Identificador da aplicação
0x00001111 . 0x4001
Código de controle
0x01 (Auto iniciar)
Descritores da aplicação()
}
Tabela 4 – Exemplo resumido de uma tabela AIT.
Dentre os descritores possíveis para a AIT destacam-se aqueles descritos, de
forma consolidada, na Tabela 5. São eles:
•
O descritor geral da aplicação que informa o perfil ao qual aquela
aplicação se destina e a versão desse perfil. No caso da tabela é
informado o Enhanced Profile com versão mínima igual a 1.1.1.
Nesse descritor pode haver mais de uma par perfil/versão. Se o
receptor der suporte a qualquer dos pares informados, estará apto a
executar a aplicação;
•
O descritor do protocolo de transporte, que pode ser um descritor
comum entre as aplicações e apresenta o identificador do protocolo e
informações específicas do mesmo. No caso da utilização do
carrossel de objetos o identificador é 0x0001 e as outras informações
disponibilizadas são: um identificador da rede original DVB-SI, um
identificador do fluxo de transporte e o identificador do serviço
DVB-SI. Esses são basicamente os mesmos elementos formadores
do localizador DVB;
•
Os descritores de informações para o usuário que incluem o
descritor de nome da aplicação (informando nome e idioma) e o
descritor de ícones da aplicação (informando uma figura pela qual o
usuário terá acesso à aplicação). Esses descritores são específicos de
Apêndice B
96
cada aplicação não podendo ser declarados juntamente com os
descritores comuns;
Os descritores específicos de aplicações DVB-J que informam: os
•
parâmetros para a aplicação; o diretório base que representa o
caminho (path) para execução da aplicação; caminhos adicionais
para classes a serem inicializadas junto com a aplicação (classpath
extensions); a classe inicial da aplicação.
Perfil da aplicação
0x1(Enhanced Profile)
Version.Major
0x1
Version.Minor
0x1
Version. Micro
0x1
Protocolo de transporte(){
0x0001
Identificador rede original
0x12
Identificador fl. De transporte
0x1
Identificador serviço
0x12
ISO_639_language_code
pt-br
Nome da aplicação
Ginga-NCL
Diretório base
/app/
Extensão ao classpath
/players
Classe inicial
GingaXlet
}
Tabela 5 – Parâmetros adicionais da AIT para sinalização do Formatador Xlet.
No caso da utilização das facilidades proporcionadas pelos plug-ins do
DVB-MHP ou Application Storage (Armazenamento de Aplicações), mais alguns
descritores spodem ser utilizados:
•
Um descritor para delegação de aplicação. Esse descritor pode ser
comum ou específico de uma aplicação e nele é especificado o
identificador da aplicação responsável por interpretar aquele
conteúdo;
•
Um descritor de plug-ins que informa qual tipo de aplicação o
plug-in é capaz de interpretar. Esse descritor deve ser informado
para cada plug-in presente na lista de aplicações;
Apêndice B
•
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 (como
jogos, por exemplo), e a versão da aplicação.
Apêndice C
A Linguagem NCL
Para a construção de aplicações interativas para sistemas de TV Digital fazse necessário o sincronismo entre as mídias envolvidas neste sistema. Além do
sincronismo do vídeo e áudio principal, o sistema de TV Digital deve ser capaz de
lidar com a sincronização espacial e temporal de objetos de diferentes tipos de
mídia.
O XHTML, usado pela maioria dos middlewares descritos neste capítulo, é
uma linguagem baseada em um modelo hipermídia bastante simples. Apesar de
sua simplicidade ser um dos fatores que contribuiu para a sua grande difusão, esta
introduz limitações como, por exemplo, o fato de permitir apenas o sincronismo
espacial. Para se obter sincronismos espaço-temporais é necessário recorrer a
recursos fora do paradigma declarativo, como o uso do ECMAScript.
O modelo hipermídia no qual foi baseado o XHTML define apenas
entidades do tipo nó e elo, sendo que existe apenas um tipo de elo (usado para
representar relações de referência), diminuindo, assim, o poder de expressão da
linguagem. Esse modelo limitado determina, ainda, que a definição dos elos esteja
contida no nó, tornando impossível reusar um documento sem herdar os elos
definidos dentro dele.
O W3C, órgão oficial que regula os padrões da World Wide Web, define o
SMIL (W3C, 2005) como linguagem oficial para o sincronismo de mídias. Nessa
linguagem, solucionando o problema do HTML, os elos não se encontram
definidos dentro dos nós. É especificada nela, ainda, uma entidade denominada
Composição. A Composição contém um conjunto de elos e nós e, no caso do
SMIL, estabelece uma semântica de sincronização. As Composições podem ser de
três tipos: paralela, seqüencial ou exclusiva. A atribuição dessa semântica às
Composições, no entanto, pode dificultar o processo de autoria quando na criação
de relacionamentos complexos. Outro fator limitante dessa linguagem é fato dela
não oferecer suporte à edição/geração ao vivo de documentos.
Apêndice C
A Linguagem NCL
99
A NCL (Nested Context Language) é uma linguagem XML para a autoria
de apresentações hipermídia, incluindo programas de TV não lineares, baseada no
modelo 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 a
semâ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 se
relacionam, no tempo e no espaço. Contudo, ao contrário do SMIL, os tipos de
conteúdo desses objetos de mídia não são restritos. Ou seja, num documento NCL
os objetos de mídia além de consistir de imagens estáticas, áudio, vídeo e texto,
amplamente implementado pelas demais linguagens, podem representar objetos
de execução (programas na linguagem Lua, JAVA,etc.) ou até documentos de
outras 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 de
documentos em tempo de apresentação, ou seja, ela permite a alteração
documento durante a sua execução. Esta funcionalidade é de grande valor em
sistemas de TV digital onde a transmissão de programas ao vivo, como eventos
esportivos, requerer uma alteração em tempo real da apresentação. Nesse
ambiente, a autoria em tempo de apresentação é realizada através do envio de
comandos 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 um
Perfil 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 que
seguem:

Estrutural – módulo Structure;
Apêndice C
A Linguagem NCL
100

Leiaute – módulo Layout;

Componentes – módulo Media e módulo Context;

Interfaces
–
módulo
CompositeNodeInterface,
MediaContentAnchor,
módulo
AttributeAnchor,
módulo
e
módulo
SwitchInterface;

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
ExtendedEntityReuse;
<?xml version="1.0" encoding="ISO-8859-1"?>
<ncl id="coisaDePele"
xmlns="http://www.ncl.org.br/NCL3.0/EDTVProfile"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.ncl.org.br/NCL3.0/EDTVProf
ile
http://www.ncl.org.br/NCL3.0/profiles/NCL30EDTV.xsd">
<head>
<regionBase>
<region height="480" id="window1" title="None"
width="640" >
<region height="200" id="imgRegion1" left="0"
top="0" width="80%"/>
<region height="280" id="logoRegion1" left="0"
top="200" width="100%"/>
<region height="50" id="fraseRegion1" left="0"
top="220" width="100%"/>
</region>
</regionBase>
<descriptorBase>
<descriptor id="img_d1" region="imgRegion1"/>
<descriptor id="logo_d1" region="logoRegion1"/>
<descriptor id="frase_d1" region="fraseRegion1">
<descriptorParam name="color" value="#FF0000" />
</descriptor>
</descriptorBase>
<connectorBase>
<importBase alias="connBase"
documentURI="coisadePele30.conn"/>
</connectorBase>
</head>
<body>
<port id="inicio" component="logotele1" />
<media type="image" descriptor="logo_d1"
id="logotele1" src="img/logo.jpg" >
<area begin="5.1s" end="10.5s" id="part1"/>
módulo
Apêndice C
A Linguagem NCL
101
</media>
<media type="image" descriptor="img_d1" id="img2"
src="img/MIDIA.jpg"/>
<media type="text" descriptor="frase_d1" id="frase"
src="frase.txt" />
<link id="link1" xconnector="connBase#onBeginStart">
<bind component="logotele1" interface="part1"
role="onBegin"/>
<bind component="img2" role="start"/>
</link>
<link id="link4" xconnector="connBase#onEndStop">
role="onEnd" />
<bind component="img2" role="stop"/>
</link>
<link id="link3" xconnector="connBase#onEndStart">
role="onEnd" />
<bind component="frase" role="start"/>
</link>
</body>
</ncl>
Figura 39 – Exemplo de documento NCL 2.0
A Figura 38 ilustra o código de um documento NCL para um melhor
entendimento da linguagem. Para maiores informações sobre essa linguagem o
leitor deve consultar (Soares & Rodrigues, 2006).

Rafael Ferreira Rodrigues Ambiente Declarativo para Sistemas que

Transcrição

Documentos relacionados

ALTERAÇÕES NA NCL_10__2013 versão para Marcelo Chimento

programação - nirema - PUC-Rio

na PUC-Rio

Houve um problema com o certificado digital do nosso

PORTE DE DOCUMENTOS E SEGUROS DE VIAGEM

Ler mais - Tecgraf - PUC-Rio

TV Digital Interativa

Múmia de Sha-amun-em-su estudada pela equipe do Seshat

Globalização e sociedade de controle - Maxwell - PUC-Rio

Certificação do Google AdWords