Rafael Ferreira Rodrigues Ambiente Declarativo para Sistemas que ...
Rafael Ferreira Rodrigues Ambiente Declarativo para Sistemas que ... Rafael Ferreira Rodrigues Ambiente Declarativo para Sistemas que ...
Introdução 14No âmbito brasileiro, encontra-se em desenvolvimento o middleware a serutilizado pelo sistema de TV digital deste país, batizado como Ginga, e parte doSistema Internacional para Difusão Digital Terrestre (Terrestrial InternationalSystem for Digital Broadcasting – ISDB-T), também conhecido como SBTVD.1.1.MotivaçãoO middleware europeu MHP, que contou com uma rápida popularização,adotou em seu ambiente procedural a linguagem JAVA (Gosling, 1996). Comisso, foi criado um nível maior de portabilidade para suas aplicações, permitindo oreuso de componentes de software provenientes de outras plataformas. Surgiram,então, algumas iniciativas para sua implementação sobre outras plataformasinternacionais. Entidades responsáveis pela padronização de sistemas de TVDigital, fora da Europa, manifestaram o interesse em ter parte do middlewareMHP implementado em suas especificações. Dessa forma, seria aproveitado todoseu desenvolvimento tecnológico e mantida uma compatibilidade que permitisseque as novas aplicações, como aquelas já desenvolvidas, pudessem serexecutadas/apresentadas em terminais de acesso desses outros padrões.Diante do interesse em se fazer uma integração entre os middlewaresprocedurais já existentes surgiu, então, o Globally Executable MHP (GEM)(ETSI, 2005a). O GEM, que pode ser considerado como um acordo deharmonização entre os principais padrões existentes, tem como base o MHP. Issoporque, além de capturar um subconjunto das interfaces, e toda a semânticadefinida por este padrão de middleware, o GEM também inclui as necessidadesimpostas por outros padrões internacionais.Com o GEM despontando como ambiente de execução procedural mínimopara os principais padrões de TV Digital (MHP, DASE e ARIB) e de mídiaempacotada (como o Blue-Ray Disc), tem-se aí uma base para a criação deaplicações e programas interativos portáveis para diversas plataformas.Middlewares procedurais compatíveis com a especificação do GEM vêm sendoadotados por vários países no mundo todo (MHP, 2006), inclusive pelo Brasil.Contudo, no GEM, como mencionado, é definido apenas um ambiente deexecução procedural, deixando livre para a implementação a definição de um
Introdução 15possível ambiente declarativo. Na Figura 1 são mostradas as especificações deambientes declarativos adotados pelos principais padrões que implementam oGEM. Nessa figura percebe-se, ainda, uma série de recomendações propostas peloórgão ITU (International Telecommunication Union).O ITU-T e ITU-R, em conjunto com outras organizações, como DVB,ARIB, ATSC, OpenCable e SMPTE, se organizaram para consolidar umatendência de harmonização que já vinha sendo demonstrada desde oestabelecimento do GEM. A recomendação ITU-T J.200 (ITU-T, 2001) foi criadavisando promover uma arquitetura de alto nível para um conjunto de formatos eAPIs mais harmônicos, capazes de prover várias funcionalidades necessárias paraaplicações interativas mais avançadas a serem oferecidas pelas redes de televisãopara os usuários domésticos. É o núcleo comum dos ambientes de aplicação paraserviços de TV Digital interativa. A recomendação estabelece tanto um ambientede execução declarativo (detalhado em ITU J.201) (ITU-T, 2004) quantoprocedural (detalhado em ITU-T J.202) (ITU-T, 2003). Contudo, esses ambientesnão precisam ser necessariamente independentes; podendo ser definidas pontesentre eles.A Figura 1 mostra a especificação ITU-T J.201 como compreendendo todoo ambiente declarativo das três principais implementações de middleware. Apesarda especificação prever um núcleo comum, mostrado no centro da áreapontilhada, é prevista sua extensão para certos requisitos específicos daimplementação.O núcleo é formado por:• Módulos definidos pelo padrão XHTML Modularization,especificado pelo W3C (World Wide Web Consortium) (W3C,2002);• O padrão CSS para descrever o estilo da apresentação, definido peloW3C (W3C, 1998);• A API DOM para alterar dinamicamente o conteúdo dosdocumentos XHTML, definida pelo W3C (W3C, 2004a); e• ECMAScript definido pela ECMA International (ECMA, 1999).Ainda na Figura 1, assim como no ambiente declarativo, a especificação doambiente procedural prevê um núcleo comum que é justamente o frameworkproposto pelo GEM. A especificação também permite a extensão desse núcleo
- Page 1 and 2: Rafael Ferreira RodriguesAmbiente D
- Page 3 and 4: Todos os direitos reservados. É pr
- Page 5 and 6: AgradecimentosGostaria de agradecer
- Page 7 and 8: AbstractRodrigues, Rafael Ferreira.
- Page 9 and 10: 4.3.1. Estrutura do Sistema Baseada
- Page 11 and 12: Figura 26 - Duas implementações d
- Page 13: 1IntroduçãoA possibilidade de se
- Page 17 and 18: Introdução 17XHTML que viabiliza
- Page 19 and 20: Introdução 19MPEG-2 para o carreg
- Page 21 and 22: 2Conceitos PreliminaresNo capítulo
- Page 23 and 24: Conceitos Preliminares 232.1.1.O Mi
- Page 25 and 26: Conceitos Preliminares 25comunicaç
- Page 27 and 28: Conceitos Preliminares 27deixam de
- Page 29 and 30: Conceitos Preliminares 29• Permit
- Page 31 and 32: Conceitos Preliminares 31são inclu
- Page 33 and 34: Conceitos Preliminares 33• Um pro
- Page 35 and 36: Conceitos Preliminares 35Dentre as
- Page 37 and 38: Conceitos Preliminares 37ocap..perm
- Page 39 and 40: Conceitos Preliminares 39No Apêndi
- Page 41 and 42: Conceitos Preliminares 41Figura 9 -
- Page 43 and 44: Conceitos Preliminares 43No GEM, po
- Page 45 and 46: Conceitos Preliminares 45Figura 13
- Page 47 and 48: 3Trabalhos RelacionadosAs propostas
- Page 49 and 50: Trabalhos Relacionados 49A proposta
- Page 51 and 52: Trabalhos Relacionados 51A soluçã
- Page 53 and 54: O Fomatador NCL 53Figura 16 - Arqui
- Page 55 and 56: O Fomatador NCL 55Como exemplo de e
- Page 57 and 58: O Fomatador NCL 574.3.A Arquitetura
- Page 59 and 60: O Fomatador NCL 59transmissão e, c
- Page 62: O Fomatador NCL 62Figura 20 - Digra
Introdução 15possível ambiente declarativo. Na Figura 1 são mostradas as especificações deambientes declarativos adotados pelos principais padrões <strong>que</strong> implementam oGEM. Nessa figura percebe-se, ainda, uma série de recomendações propostas peloórgão ITU (International Telecommunication Union).O ITU-T e ITU-R, em conjunto com outras organizações, como DVB,ARIB, ATSC, OpenCable e SMPTE, se organizaram <strong>para</strong> consolidar umatendência de harmonização <strong>que</strong> já vinha sendo demonstrada desde oestabelecimento do GEM. A recomendação ITU-T J.200 (ITU-T, 2001) foi criadavisando promover uma arquitetura de alto nível <strong>para</strong> um conjunto de formatos eAPIs mais harmônicos, capazes de prover várias funcionalidades necessárias <strong>para</strong>aplicações interativas mais avançadas a serem oferecidas pelas redes de televisão<strong>para</strong> os usuários domésticos. É o núcleo comum dos ambientes de aplicação <strong>para</strong>serviços de TV Digital interativa. A recomendação estabelece tanto um ambientede execução declarativo (detalhado em ITU J.201) (ITU-T, 2004) quantoprocedural (detalhado em ITU-T J.202) (ITU-T, 2003). Contudo, esses ambientesnão precisam ser necessariamente independentes; podendo ser definidas pontesentre eles.A Figura 1 mostra a especificação ITU-T J.201 como compreendendo todoo ambiente declarativo das três principais implementações de middleware. Apesarda especificação prever um núcleo comum, mostrado no centro da áreapontilhada, é prevista sua extensão <strong>para</strong> certos requisitos específicos daimplementação.O núcleo é formado por:• Módulos definidos pelo padrão XHTML Modularization,especificado pelo W3C (World Wide Web Consortium) (W3C,2002);• O padrão CSS <strong>para</strong> descrever o estilo da apresentação, definido peloW3C (W3C, 1998);• A API DOM <strong>para</strong> alterar dinamicamente o conteúdo dosdocumentos XHTML, definida pelo W3C (W3C, 2004a); e• ECMAScript definido pela ECMA International (ECMA, 1999).Ainda na Figura 1, assim como no ambiente declarativo, a especificação doambiente procedural prevê um núcleo comum <strong>que</strong> é justamente o frameworkproposto pelo GEM. A especificação também permite a extensão desse núcleo