Rafael Ferreira Rodrigues Ambiente Declarativo para Sistemas que ...
Rafael Ferreira Rodrigues Ambiente Declarativo para Sistemas que ... Rafael Ferreira Rodrigues Ambiente Declarativo para Sistemas que ...
Conceitos Preliminares 26utilizado para capturar, processar e apresentar alguns tipos de mídiascontínuas.• HAVi User-Interface: é uma API que permite ao programador criarelementos para a interface com o usuário. Provê uma extensão ao pacote“java.awt”, permitindo, assim, suporte a controle remoto, transparência,entre outros;• DAVIC: Apresenta alguns requisitos de sistemas audiovisuais paraprover interoperabilidade fim-a-fim;• DVB-MHP: Essa API utiliza os serviços providos pelas classes dasAPIs já mencionadas (ou seja, na prática provendo a mesmafuncionalidade) e adiciona serviços novos, como gerenciamento daconexão do canal de retorno, armazenamento de informações,manipulação de eventos, segurança, gerenciamento de aplicações ecarregamento de plug-ins.O MHP fornece dois mecanismos auxiliares que permitem a instalação deaplicações de forma persistente nos receptores dos usuários. São eles: o uso dosplug-ins e o Application Storage (armazenamento de aplicações). Nas subseçõesseguintes serão apresentados esses dois mecanismos.2.1.1.2.O uso de Plug-insPlug-ins são conjuntos de funcionalidades que podem ser adicionadas a umaplataforma genérica de forma a prover a interpretação de formatos de aplicaçãoregistrados junto ao DVB. Atualmente, encontram-se registrados dois formatos deaplicações: o HTML 3.2, que também indica aplicações no formato XHTML esuas derivadas como o DVB-HTML, e o MHEG-5 (ISO, 1997). A Figura 5mostra os dois tipos possíveis de plug-ins: nativos (na figura como plug-in B) einteroperáveis (na figura como plug-in A).Os plug-ins nativos usam código específico da implementação do receptor,ou seja, código nativo. Esse tipo de código pode, inclusive, ser especificado nalinguagem Java, desde que não sejam utilizadas as APIs do MHP, caso contrario,
Conceitos Preliminares 27deixam de ser considerados nativos. O processo de sinalização das aplicações 1 ,tanto do plug-in como das aplicações por ele processadas, também deverá sernativo.Figura 5 – Opções de implementação de plug-ins.Já um plug-in interoperável é aquele que necessita apenas das APIsespecificadas pelo padrão MHP, permitindo dois tipos de sinalização: umafornecida pelo padrão e outra específica da implementação.A sinalização padrão do MHP para plug-ins, prevê a existência de doistipos de descritores a serem utilizados pela tabela AIT: um descritor de aplicaçãopara o plug-in e outro para a aplicação por ele processada. Esses descritores sãomostrados em mais detalhes no Apêndice B. A sinalização prevê, ainda, que oponto de entrada do plug-in seja uma classe que implemente a interfaceorg.dvb.application.plugins.Plugin mostrada na Figura 6. Com isso, asaplicações processadas por ele serão reconhecidas como Xlets e controladas peloGerenciador de Aplicações.Na sinalização específica da implementação, a aplicação processada peloplug-in não será reconhecida como uma aplicação MHP (Xlet). Com isso todo seucontrole (ciclo de vida, etc.) deverá ser realizado pelo próprio plug-in.1 A sinalização de aplicações define formas de se identificar e iniciar aplicações associadasa um serviço. Ela deve também oferecer mecanismos pelos quais as difusoras possam gerenciar ociclo de vida de suas aplicações.
- 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 and 14: 1IntroduçãoA possibilidade de se
- Page 15 and 16: Introdução 15possível ambiente d
- 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: Conceitos Preliminares 25comunicaç
- 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
- Page 65 and 66: O Fomatador NCL 65Figura 22 - Diagr
- Page 67 and 68: O Fomatador NCL Xlet 675.1.1.Gerenc
- Page 69 and 70: O Fomatador NCL Xlet 695.1.3.Núcle
- Page 71 and 72: O Fomatador NCL Xlet 71Esse compone
- Page 73 and 74: O Fomatador NCL Xlet 73criar uma in
- Page 75 and 76: O Fomatador NCL Xlet 75finalizaçã
Conceitos Preliminares 27deixam de ser considerados nativos. O processo de sinalização das aplicações 1 ,tanto do plug-in como das aplicações por ele processadas, também deverá sernativo.Figura 5 – Opções de implementação de plug-ins.Já um plug-in interoperável é a<strong>que</strong>le <strong>que</strong> necessita apenas das APIsespecificadas pelo padrão MHP, permitindo dois tipos de sinalização: umafornecida pelo padrão e outra específica da implementação.A sinalização padrão do MHP <strong>para</strong> plug-ins, prevê a existência de doistipos de descritores a serem utilizados pela tabela AIT: um descritor de aplicação<strong>para</strong> o plug-in e outro <strong>para</strong> a aplicação por ele processada. Esses descritores sãomostrados em mais detalhes no Apêndice B. A sinalização prevê, ainda, <strong>que</strong> oponto de entrada do plug-in seja uma classe <strong>que</strong> implemente a interfaceorg.dvb.application.plugins.Plugin mostrada na Figura 6. Com isso, asaplicações processadas por ele serão reconhecidas como Xlets e controladas peloGerenciador de Aplicações.Na sinalização específica da implementação, a aplicação processada peloplug-in não será reconhecida como uma aplicação MHP (Xlet). Com isso todo seucontrole (ciclo de vida, etc.) deverá ser realizado pelo próprio plug-in.1 A sinalização de aplicações define formas de se identificar e iniciar aplicações associadasa um serviço. Ela deve também oferecer mecanismos pelos quais as difusoras possam gerenciar ociclo de vida de suas aplicações.
Change language