Middleware Ginga. Jean Ribeiro Damasceno. Escola de Engenharia Universidade Federal Fluminense (UFF) RuaPassoda Pátria, 156 Niterói RJ Brasil

Transcrição

1 Fundamentos de Sistemas Multimídia Prof. ª Débora C. Muchaluat Saade Middleware Ginga Jean Ribeiro Damasceno Escola de Engenharia (UFF) RuaPassoda Pátria, 156 Niterói RJ Brasil

2 Introdução Ginga é o nome do middleware aberto do Sistema Brasileiro de TV Digital Ginga é uma camada de software intermediário (middleware), entre o hardware/sistema Operacional e as aplicações As aplicações executadas sobre Ginga são classificadas em duas categorias - Aplicações declarativas - Aplicações procedurais O usuário deixa de ter um papel passivo de telespectador e passa a ter um papel ativo Todas as propostas de sistemas de Televisão Digital especificam middlewares No Brasil, o uso da TV como objeto de inclusão digital é prioridade do governo

3 Arquitetura do Middleware Ginga Em TV o Modelo de serviço é do tipo push Usuários podem começar a assistir um programa já iniciado Possibilidade de edição de documentos durante a exibição A melhor forma de lidar com um sistema complexo como é o caso de um sistema de TV digital interativa é através da representação de sua arquitetura Arquitetura: - Mostra os principais elementos de um sistema - Explicita suas interações - Esconde os detalhes menos importantes

4 Arquitetura do Middleware Ginga Figura 1. Arquitetura de TV digital com tecnologias usadas em cada camada Figura 2. Padrões de referência do sistema brasileiro de TV digital

5 Arquitetura do Middleware Ginga Requisitos de um middleware: Suporte àsincronização de mídias - Sincronização baseada na estrutura - Suporte a canal de retorno Suporte a múltiplos dispositivos de exibição Suporte ao desenvolvimento de programas ao vivo (em tempo de exibição) Suporte à adaptação do conteúdo e da forma como o conteúdo é exibido

6 Arquitetura do Middleware Ginga po Figura 3. Importância da TV na Inclusão Social

7 Arquitetura do Middleware Ginga O middleware Ginga pode ser dividida em três grandes módulos: Ginga-NCL (declarativo) (o ambiente de apresentação) Ginga-J (procedural) (o ambiente de execução ) Ginga-CC (Common Core)

8 Arquitetura do Middleware Ginga Figura 4. Arquitetura do middleware Ginga

9 Arquitetura do Middleware Ginga Ginga NCL: Ambiente obrigatório para receptores portáteis e fixos Máquina de interpretação do conteúdo declarativo (formatador NCL) Exibidor (user agent) XHTML Máquina de apresentação Lua

10 Arquitetura do Middleware Ginga Ginga NCL: Linguagem NCL (Nested Context Language) (oferece suporte a todos os requisitos mencionados para um middleware) Desenvolvida no Laboratório TeleMídia da PUC-Rio NCL é uma das principais linguagens existentes para a definição do sincronismo temporal NCL também provê suporte a variáveis NCL foi concebida de forma modular

11 Arquitetura do Middleware Ginga Ginga NCL: Lua Desenvolvida no Departamento de Informática da PUC-Rio Padrão internacional de fato na área de entretenimento Lua é leve, fácil de usar e possui um altíssimo desempenho

12 Arquitetura do Middleware Ginga Ginga Java: É uma especificação de middleware distribuído Deve ser capaz de receber e interpretar os dados dos celulares, PDAs, controles, etc. Figura 6. Contexto em que a pilha do software Ginga-J é executada

13 Arquitetura do Middleware Ginga Ginga Java: Máquina virtual Java Ginga-J não é mandatário para todos os perfis de terminais de acesso A definição Ginga-J é composta por API (Interfaces de Programação de Aplicativos) O subsistema foi construído para garantir a compatibilidade com o padrão GEM Desenvolvido no Laboratório LAVID da UFPB

14 Arquitetura do Middleware Ginga Ginga Java: O ambiente de execução Ginga-J utiliza a linguagem Java e é dividido em três partes Figura 7. Ginga-J. APIs vermelha, amarela e verde do Ginga-J.

15 Arquitetura do Middleware Ginga Ginga Common Core : Concentra serviços necessários tanto para a máquina de apresentação (declarativo) quanto para a máquina de execução (procedural) Faz a interface direta com o sistema operacional, fazendo uma ponte estreita com o hardware

16 Arquitetura do Middleware Ginga Ginga Common Core : Figura 9. Ginga Common Core

17 Middlewares Adotados em outros Sistemas de TV Digital A padronização evita uma proliferação de padrões de middleware Seguem recomendações do padrão GEM Middlewares: - MHP Multimedia Home Platform (Europeu) - DASE DTV Application Software Environment (Americano) - ARIB Association of Radio Industries and Businesses (Japonês)

18 Middlewares Adotados em outros Sistemas de TV Digital MHP Multimedia Home Platform (Europeu) Busca oferecer um ambiente de TV interativa, independente de hardware e software específicos, aberto e interoperável, para receptores e set top boxes de TV digital. Ambiente de execução: - máquina virtual Java - conjunto de interfaces de programação de aplicações (APIs) Possibilidade de usar uma linguagem de programação semelhante ao HTML, denominada DVB- HTML. Além do MHP, o MHEG-5 (padrão ISO/IEC ) é adotado na camada de middleware no DVB-T.

19 Middlewares Adotados em outros Sistemas de TV Digital MHP Multimedia Home Platform (Europeu) Figura 10. O padrão de televisão digital DVB MHP

20 Middlewares Adotados em outros Sistemas de TV Digital DASE DTV Application Software Environment (Americano) Adota uma máquina virtual Java como mecanismo que facilita a execução de aplicações que permitem interatividade Permite o uso de linguagens declarativas, usadas na web, como HTML e JavaScript Os middlewares MHP e DASE não foram projetados para serem compatíveis entre si

21 Middlewares Adotados em outros Sistemas de TV Digital DASE DTV Application Software Environment (Americano) Figura 11. O padrão de televisão digital ATSC DASE

22 Middlewares Adotados em outros Sistemas de TV Digital DASE DTV Application Software Environment (Americano) Está sendo substituído pelo ACAP (Advanced Common Application Platform) e OCAP (OpenCable Applications Platform) nos EUA O ACAP é o resultado da harmonização dos padrões de middleware OCAP do CableLabs, e DASE, do ATSC, que assegura compatibilidade entre as transmissões por cabo e terrestres Assim como o OCAP, o ACAP é derivado do padrão MHP por meio da especificação GEM O OCAP é voltado para as plataformas de TV a cabo, e o principal objetivo de sua especificação é permitir que as aplicações sejam executadas em qualquer sistema dos EUA

23 Middlewares Adotados em outros Sistemas de TV Digital ARIB Association of Radio Industries and Businesses (Japonês) O middleware do ISDB (Integrated Services Digital Broadcasting) É padronizado pela organização japonesa ARIB É formado por alguns padrões, como o ARIB STD-B24 (Data Coding and Transmission Specification for Digital Broadcasting) que define uma linguagem declarativa denominada BML (Broadcast Markup Language) Outra especificação do middleware é o ARIB-STD B23 (Application Execution Engine Platform for Digital Broadcasting

24 Middlewares Adotados em outros Sistemas de TV Digital ARIB Association of Radio Industries and Businesses (Japonês) Figura 12. O padrão de televisão digital ISDB ARIB

25 Middlewares Adotados em outros Sistemas de TV Digital GEM Globally Executable MHP O GEM 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). 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: - um conjunto de APIs - garantias semânticas - protocolos - formatos de conteúdo

26 Middlewares Adotados em outros Sistemas de TV Digital GEM Globally Executable MHP Figura 13. O GEM e a relação com middlewares de outros padrões de TV Digital

27 Comparação do Middleware Ginga com os Middlewares adotados em outros Sistemas de TV Digital Middleware Sistema de TVD Ambiente Declarativo Ambiente Procedural ACAP Americano/ATSC ACAP-X [ATSC A ] (linguagem declarativa = XHTML) like; linguagem não-declarativa = ECMAScript) ACAP-J [ATSC A ] (linguagem procedural = Java) MHP Europeu/DVB-T DVB-HTML [ETSI TS V1.2.2, 2006] (linguagem declarativa = XHTML like; linguagem não-declarativa = ECMAScript) MHP [ETSI TS V1.2.2, 2006] (linguagem procedural = Java) ARIB-BML Japonês/ISDB-T ARIB BML [ARIB B ] (linguagem declarativa = BML (XHTML like; linguagem não-declativa= ECMAScript) Opcional (GEM [ETSI TS V ] like); não implementado) Ginga Brasileiro/SBTV Ginga-NCL [ABNT NBR ] (linguagem declarativa = NCL; linguagem não declarativa = Lua) Ginga-J (Linguagem procedural = Java) Tabela 1. Ambientes de aplicações para receptores fixos e móveis

28 Comparação do Middleware Ginga com os Middlewares adotados em outros Sistemas de TV Digital Middleware Sistema de TVD Ambiente Declarativo Ambiente Procedural ARIB-BML Japonês/ISDB-T ARIB-BML [ARIB B ] (linguagem declarativa = BML (XHTML like; linguagem nãodeclarativa = ECMAScript) X Ginga Brasileiro/SBTVD Ginga-NCL [ABNT NBR ] (linguagem declarativa = NCL; linguagem não-declarativa = Lua) Opcional o Ginga-J Tabela 2. Ambientes de aplicações para receptores portáteis

29 Comparação do Middleware Ginga com os Middlewares adotados em outros Sistemas de TV Digital No Ginga os ambientes de apresentação e execução se complementam, unidos por uma ponte em uma implementação sem nenhuma redundância O Ginga, desde seu projeto inicial, foi desenvolvido tendo em mente os dois ambientes de programação. A BML e o Ginga-NCL parecem ser, atualmente, os mais apropriados para servirem de middleware em dispositivos portáteis NCL BML - Mais apropriada para o desenvolvimento de aplicações hipermídia Foco no sincronismo e adaptabilidade Baseada em XHTML Foco declarativo apenas na interatividade, se comparada a BML, é mais apropriada para o desenvolvimento de aplicações hipermídia e, principalmente, de TV Digital. Isso porque têm foco no sincronismo e adaptabilidade, fatores importantes no desenvolvimento de aplicações de TV Digital. A BML é baseada em XHTML e tem foco declarativo apenas na interatividade.

30 Conclusão O Ginga da suporte às aplicações declarativas e procedurais O Ginga é compatível com as definições internacionais ITU - Possibilita a exportação do conteúdo Tanto o ambiente declarativo quanto o procedural de um middleware deve dar suporte: - a sincronização de mídias, - a múltiplos dispositivos de exibição, - ao desenvolvimento de programas ao vivo (em tempo de exibição) - suporte à adaptação do conteúdo e da forma como o conteúdo é exibido Um middleware nacional fortalece a indústria nacional de software

31 Fundamentos de Sistemas Multimídia Prof. ª Débora C. Muchaluat Saade Middleware Ginga Jean Ribeiro Damasceno Obrigado! Perguntas?