2011 ManoelCamposSilvaFilho PDF

ARQUITETURA ORIENTADA A SERVIC OS
PARA COM
ERCIO ELETR

ONICO NO
SISTEMA BRASILEIRO DE TV DIGITAL
MANOEL CAMPOS DA SILVA FILHO
DISSERTAC

AO DE MESTRADO EM ENGENHARIA EL
ETRICA
DEPARTAMENTO DE ENGENHARIA EL
ETRICA
FACULDADE DE TECNOLOGIA
UNIVERSIDADE DE BRAS
ILIA
ILIA
ETRICA
PARA COM
ERCIO ELETR
ONICO NO
Orientador: PROF. DR. PAULO ROBERTO DE LIRA GONDIM, ENE/UNB
DISSERTAC

AO DE MESTRADO EM ENGENHARIA EL
ETRICA
PUBLICAC

AO PPGENE.DM - 439/2011
BRAS
ILIA-DF, 16 DE JUNHO DE 2011.

ILIA
ETRICA
PARA COM
ERCIO ELETR
ONICO NO
DISSERTAC

AO DE MESTRADO ACAD
EMICO SUBMETIDA AO DEPARTAMENTO DE

ENGENHARIA EL
ETRICA DA FACULDADE DE TECNOLOGIA DA UNIVERSIDADE DE

BRAS
ILIA, COMO PARTE DOS REQUISITOS NECESS
ARIOS PARA A OBTENC

AO DO
GRAU DE MESTRE EM ENGENHARIA EL
ETRICA.
APROVADA POR:
Prof. Dr. Paulo Roberto de Lira Gondim, ENE/UnB
Orientador
Prof. Dr. Divanilson Rodrigo Campelo, ENE/UnB
Examinador interno
Prof. Dr. Dbio Leandro Borges, CIC/UnB
Examinador externo
BRAS
ILIA, 16 DE JUNHO DE 2011.

FICHA CATALOGR
AFICA
Arquitetura orientada a servicos para com ercio eletr onico no Sistema Brasileiro de TV
Digital
2011xv, 107p., 201x297 mm
(ENE/FT/UnB, Mestre, Engenharia El etrica, 2011)
Dissertac ao de Mestrado - Universidade de Braslia
Faculdade de Tecnologia - Departamento de Engenharia El etrica
REFER
ENCIA BIBLIOGR
AFICA
MANOEL CAMPOS DASILVAFILHO(2011) Arquitetura orientada a servicos para com ercio
eletr onico no Sistema Brasileiro de TV Digital. Dissertac ao de Mestrado em Engenha-
ria El etrica, Publicac ao 439/2011, Departamento de Engenharia El etrica, Universidade de
Braslia, Braslia, DF, 107p.
CESS
AO DE DIREITOS
AUTOR: Manoel Campos da Silva Filho
T
ITULO: Arquitetura orientada a servicos para com ercio eletr onico no Sistema Brasileiro de
TV Digital.
GRAU: Mestre ANO: 2011
E concedida ` a Universidade de Braslia permiss ao para reproduzir c opias desta dissertac ao de

Mestrado e para emprestar ou vender tais c opias somente para prop ositos acad emicos e ci-
entcos. O autor se reserva a outros direitos de publicac ao e nenhuma parte desta dissertac ao
de Mestrado pode ser reproduzida sem a autorizac ao por escrito do autor.
Manoel Campos da Silva Filho
Universidade de Braslia, Faculdade de Tecnologia, Departamento de Engenharia
El etrica, 70910-900, Braslia-DF, Brasil.
Agradecimentos
Gostaria de agradecer primeiramente ao Instituto Federal de Educac ao, Ci encia e Tecno-
logia do Tocantins (IFTO), instituic ao onde leciono, por ter me liberado por dois anos para
cursar o programa de mestrado em Engenharia El etrica da Universidade de Braslia; ` a CA-
PES pela ajuda nanceira durante este perodo; e um agradecimento especial a meus grandes
amigos e companheiros (em ordem alfab etica) Cl audio Monteiro, Helder Cleber, Leandro
Vaguetti, Lilissanne Marcelly, Maurcio J unior, Vanice Cunha e Vincius Rios, que tornaram
esta jornada menos cansativa e mais divertida, que foram amigos de todas as horas, tanto nas
de alegria quanto nas de tristeza. Por m, e n ao menos importante, gostaria de agradecer a
meu orientador, o professor Paulo Gondim, por todos os ensinamentos e apoio durante esta
jornada.
i
Resumo
Arquitetura orientada a servicos para com ercio eletr onico
no Sistema Brasileiro de TV Digital
Esta dissertac ao descreve uma arquitetura orientada a servicos para provimento de
com ercio eletr onico pela TV Digital, por meio do Sistema Brasileiro de TV Digital
(SBTVD), desenvolvida para o sub-sistema Ginga-NCL do middleware Ginga. A arquitetura
proposta utiliza servicos de diferentes provedores (nas areas de telecomunicac oes, logstica e
outros) para compor uma estrutura de T-Commerce. Tais servicos s ao desenvolvidos conside-
rando aspectos de interoperabilidade, utilizando o protocolo SOAP, para o qual e apresentada
uma implementac ao, juntamente com o HTTP, como base para o desenvolvimento de toda a
arquitetura e um dos objetivos principais do projeto.
Com a arquitetura elaborada, uma aplicac ao cliente, desenvolvida em NCL e Lua, e apre-
sentada como prova de conceito do uso das implementac oes dos protocolos e da arquitetura
proposta. Tal aplicac ao utiliza o framework LuaOnTV para a construc ao da interface gr aca
de usu ario para a TV Digital, o qual foi estendido neste trabalho, com as melhorias sendo
apresentadas ao longo do mesmo.
O trabalho ainda apresenta um conjunto de aplicac oes desenvolvidas a partir dos fra-
meworks construdos, que complementam as funcionalidades da aplicac ao de T-Commerce,
como leitor de RSS e rastreamento de encomendas.
A partir do ambiente de desenvolvimento montado para a construc ao das aplicac oes,
contendo a implementac ao de refer encia do sub-sistema Ginga-NCL do middleware Ginga,
nativamente instalada, foi gerada uma distribuic ao Linux que permite que tal ambiente seja
instalado em qualquer computador ou m aquina virtual, para permitir o desenvolvimento de
arquitetura semelhante ou extens ao da arquitetura proposta.
Palavras-chave: SBTVD, Ginga, Ginga-NCL, Web Services, HTTP, SOAP, SOA, Lua,
NCL, NCLua, NCLua HTTP, NCLua SOAP, LuaOnTV 2.0, E-Commerce, T-Commerce
ii
Abstract
Service-oriented architecture for electronic commerce in the
Brazilian Digital Television System
This dissertation describes a service-oriented architecture for providing of digital TV
electronic commerce, through the Brazilian Digital Television System, developed to the
Ginga-NCL sub-system of the Brazilian Ginga middleware. The proposed architecture uses
services from distinct providers (at telecommunication, logistics and other areas) to compose
a T-Commerce structure. Such services are developed considering interoperability aspects,
using the SOAP protocol, for wich is presented an implementation, together with the HTTP
protocol, as a basis for the development of the entire architecture and one of the project main
goals.
With the architecture designed, a client application, developed in NCL and Lua langua-
ges, is presented as a proof of concept of the protocols implementations and proposed archi-
tecture use. Such application uses the LuaOnTV framework to build a Digital TV graphical
user interface, wich was extended in this dissertation, with the improvements being presented
along it.
The work also presents a set of applications developed from the constructed frameworks
that complement the T-Commerce application functionalities, such as RSS reader and orders
tracking.
From the mounted development environment for applications building, containing the
reference implementation of the Ginga-NCL sub-system of the Ginga middleware, natively
installed, a Linux distribution was generated that enables such environment to be installed
on any computer or virtual machine, to allow the development of similar architecture or
extension of the proposed one.
Keywords: ISDB-TB, Ginga, Ginga-NCL, Web Services, HTTP, SOAP, SOA, Lua,
NCL, NCLua, NCLua HTTP, NCLua SOAP, LuaOnTV 2.0, E-Commerce, T-Commerce
iii
SUM
ARIO
RESUMO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . II
ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III
1 INTRODUC

AO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 OBJETIVOS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 GERAL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 ESPEC
IFICOS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 JUSTIFICATIVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 METODOLOGIA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 ORGANIZAC

AO DO TRABALHO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 REVIS
AO BIBLIOGR
AFICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1 COM
ERCIO ELETR
ONICO: E-Commerce, M-Commerce E T-Commerce. . . . 10

2.2 SISTEMA BRASILEIRO DE TV DIGITAL (SBTVD) . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 A TECNOLOGIA DE Web Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.1 PROTOCOLOS DE COMUNICAC

AO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.2 DESCRIC

AO DE SERVIC OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.3 DESCOBERTA DE SERVIC OS COM UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.4 Web Services REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.5 ARQUITETURA ORIENTADA A SERVIC OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3 ARQUITETURA DE COM
ERCIO ELETR
ONICO PARA A TV DIGITAL . . . . . . . . . . 27

3.1 REQUISITOS DA ARQUITETURA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 APRESENTAC

AO GERAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.1 CASOS DE USO DAS FUNCIONALIDADES DA ARQUITETURA . . . . . . . . . . . . . 32
3.2.2 TECNOLOGIAS Core DA ARQUITETURA PROPOSTA . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3 DESCRIC

AO DOS COMPONENTES DE Software DA ARQUITETURA. . . . . . . . 34
3.4 DIAGRAMA DE DISTRIBUIC

AO/IMPLANTAC

AO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.5 AMBIENTE DE DESENVOLVIMENTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.6 DISTRIBUIC

AO GNU/LINUX P/ DESENVOLVIMENTO DE APLICAC

OES . . 49
4 FRAMEWORK LUAONTV 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1 DELIMITAC

AO DO PROBLEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
iv
4.2 LUAONTV 2.0: NOVA VERS
AO IMPLEMENTADA . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2.1 MELHORIA DE DESEMPENHO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2.2 TEMAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5 FRAMEWORK DE COMUNICAC

AO DE DADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.1 INTEGRAC

AO ENTRE Web E TV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2 DELIMITAC

AO DO PROBLEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.3 TECNOLOGIAS ENVOLVIDAS E TRABALHOS RELACIONADOS . . . . . . . . . . . . 61
5.3.1 TECNOLOGIAS DE Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.3.2 LUA E OS scripts NCLUA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.3.3 PROTOCOLO TCP NO GINGA-NCL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.3.4 IMPLEMENTAC

OES DE SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.4 PROPOSTA DE NOVAS IMPLEMENTAC

OES DE HTTP E SOAP . . . . . . . . . . . . 66
5.4.1 DECIS
OES DE PROJETO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.4.2 NCLUA HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.4.3 NCLUA SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.5 EXEMPLOS DE USO E TESTES DE INTEROPERABILIDADE . . . . . . . . . . . . . . . . . 70
5.5.1 EXEMPLOS DE USO DO NCLUA HTTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.5.2 EXEMPLOS DE USO DO NCLUA SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.6 AMBIENTE DE DESENVOLVIMENTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.7 AVALIAC

AO DE DESEMPENHO E COMPARAC

OES . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.7.1 AVALIAC

AO DE DESEMPENHO DO NCLUA SOAP . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.7.2 COMPARATIVO ENTRE OS M
ODULOS IMPLEMENTADOS E O TCP.LUA . . . . 76

5.7.3 COMPARATIVO ENTRE O NCLUA SOAP E OUTRAS IMPLEMENTAC

OES . 76
5.8 LIMITAC

OES DO M
ODULO NCLUA SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6 CONCLUS
OES E TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6.1 CONCLUS
OES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.2 TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
REFER
ENCIAS BIBLIOGR
AFICAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
AP
ENDICE A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
SCREENSHOTS DA APLICAC

AO DE T-Commerce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
LISTA DE FIGURAS
2.1 Arquitetura de Aplicac ao Distribuda (adaptada de [InterSystems 2010]). ....... 15
2.2 Arquitetura conceitual de sistemas orientados a servicos............................. 17
2.3 Organizac ao da Especicac ao do WSDL................................................. 24
3.1 Vis ao Geral da Arquitetura SOA proposta para T-Commerce ....................... 29
3.2 Diagrama de Casos de Uso: Funcionalidades providas a desenvolvedores....... 32
3.3 Diagrama de Casos de Uso: Funcionalidades providas aos usu arios .............. 33
3.4 Tecnologias Core da arquitetura de T-Commerce....................................... 34
3.5 Aplicac ao de T-Commerce: Tela inicial mostrando os produtos em destaque ... 36
3.6 Aplicac ao de T-Commerce: Diagrama de sequ encia do processo de compra .... 37
3.7 NCLua RSS Reader - Leitor de Notcias para TV Digital ............................ 38
3.8 Rastreamento de encomendas pela TVD: Inserc ao do c odigo de rastreamento . 39
3.9 Rastreamento de encomendas pela TVD: Situac ao da entrega da encomenda .. 40
3.10 Diagrama de Classes dos Web Services implementados .............................. 41
3.11 Diagrama das classes utilizadas internamente pelos WSs implementados ...... 42
3.12 Web Service dos Correios: Calculando preco e prazo de entrega de encomenda 44
3.13 Arquitetura de T-Commerce: Diagrama de Distribuic ao/Implantac ao............. 46
4.1 Novo diagrama de classes do LuaOnTV.................................................. 57
4.2 Gr aco de M aquinas de Estados da classe EventManager ........................... 58
4.3 Classes relacionadas ao novo recurso de temas do LuaOnTV....................... 58
4.4 Diagrama de Componentes do LuaOnTV ................................................ 59
5.1 Diagrama de M aquinas de Estados do M odulo tcp.lua................................ 64
5.2 Diagrama de M aquinas de Estados do M odulo tcp.lua (co-rotinas em execuc ao) 65
5.3 Diagrama de Componentes do NCLua SOAP e NCLua HTTP ..................... 70
6.1 Aplicac ao de T-Commerce: Tela inicial com produtos em destaque ............... 87
6.2 Aplicac ao de T-Commerce: Busca de produtos ......................................... 87
6.3 Aplicac ao de T-Commerce: Login (utilizando e-mail ou CPF)...................... 88
6.4 Aplicac ao de T-Commerce: Recuperar senha por e-mail ou SMS.................. 88
6.5 Aplicac ao de T-Commerce: Cadastro de Clientes ...................................... 89
6.6 Aplicac ao de T-Commerce: Cadastro de Enderecos ................................... 89
6.7 Aplicac ao de T-Commerce: Selec ao de Enderecos ..................................... 90
vi
6.8 Aplicac ao de T-Commerce: Formas de Pagamento .................................... 90
6.9 Aplicac ao de T-Commerce: Finalizar Compra .......................................... 91
LISTA DE TABELAS
3.1 Requisitos da Arquitetura de T-Commerce ............................................... 28
3.2 Requisitos funcionais e n ao funcionais da aplicac ao de T-Commerce ............. 35
4.1 Requisitos implementados na nova vers ao do LuaOnTV............................. 53
5.1 Avaliac ao de Desempenho do NCLua SOAP............................................ 74
5.2 Comparativo entre aplicac oes de TVD sem e com os m odulos implementados 76
5.3 Comparac ao entre NCLua SOAP e outros toolkits SOAP............................ 77
6.1 Objetivos Especcos Alcancados.......................................................... 80
viii
LISTA DE C

ODIGOS FONTE
2.1 Estrutura de um envelope SOAP [Curbera et al. 2002] ............................... 17
2.2 Envelope SOAP transportado via HTTP [Curbera et al. 2002]...................... 18
2.3 Chamada SOAP RPC empacotada em HTTP [Curbera et al. 2002] ............... 19
2.4 Resposta de requisic ao SOAP empacotada em HTTP [Curbera et al. 2002] .... 20
2.5 Fragmento de uma descric ao de WSDL [Curbera et al. 2002] ...................... 22
2.6 Informac oes concretas de ligac ao em um WSDL [Curbera et al. 2002] .......... 23
5.1 Exemplo de tabela Lua gerada a partir do XML de uma resposta SOAP ......... 68
5.2 Exemplo de simplicac ao de retorno de resposta SOAP pelo NCLua SOAP ... 69
5.3 Exemplo de envio de requisic ao GET com NCLua HTTP ........................... 70
5.4 Exemplo de consumo de Web Service de previs ao do tempo ........................ 71
5.5 Exemplo de consumo de WS de consulta de endereco a partir do CEP........... 72
ix
LISTA DE TERMOS E SIGLAS
AJAX Asynchronous Javascript And XML
API Application Programming Interface
ATSC Advanced Television Systems Committee
B2B Business-to-Business
B2C Business-to-Consumer
BPEL Business Process Execution Language
CASE Computer-Aided Software Engineering
CEP C odigo de Enderecamento Postal
CETIC.br Centro de Estudos sobre as Tecnologias da Informac ao e da Comunicac ao
CGI.br Comit e Gestor da Internet no Brasil
COM+ Component Object Model Plus
CORBA Common Object Request Broker Architecture
CSS Cascade Style Sheets
DAO Data Access Objects
DCOM Distributed Component Object Model
DVB Digital Video Broadcast
E-Commerce Com ercio Eletr onico
EAI Enterprise Application Integration
ECT Empresa Brasileira de Correios e Tel egrafos
EDI Eletronic Data Interchange
HTML HyperText Markup Language
x
HTTP HyperText Transfer Protocol
IDE Integrated Development Environment
ISDB-T Integrated Services Digital Broadcasting Terrestrial
Java EE Java Enterprise Edition
JAX Java API for XML
JAX-WS Java API for XML Web Services
JDBC Java Database Connectivity
JDK Java Development Kit
JPA Java Persistent API
JRE Java Runtime Environment
JSON JavaScript Object Notation
LAN Local Area Network
LWUIT Light Weight UI Toolkit
M-Commerce Com ercio M ovel
MIME Multipurpose Internet Mail Extensions
MTA Mail Transfer Agent
NCL Nested Context Language
NIC.br N ucleo de Informac ao e Coordenac ao do Ponto BR
OO Orientac ao a Objetos
PNBL Plano Nacional de Banda Larga
REST Representational State Transfer
RIA Rich Internet Application
RMI Remote Method Invocation
RPC Remote Procedure Call
RSS Really Simple Syndication
SBTVD Sistema Brasileiro de TV Digital
SBTVD-T Sistema Brasileiro de Televis ao Digital Terrestre
SGBD Sistema Gerenciador de Banco de Dados
SMS Short Message Service
SMTP Simple Mail Transfer Protocol
SOA Service Oriented Architecture
SOAP Simple Object Access Protocol
SQL Structured Query Language
STB Set-top Box (Conversor Digital)
T-Commerce Com ercio pela TV Digital
UBR UDDI Business Registry
UDDI Universal Description, Discovery and Integration
UML Unied Modeling Language
UMTS Universal Mobile Telecommunications System
URI Uniform Resource Identier
URL Uniform Resource Locator
W3C World Wide Web Consortium
Web, WWW World Wide Web
WLAN Wireless Local Area Network
WS Web Service
WSDL Web Service Description Language
XML eXtensible Markup Language
XSD XML Schema Denition
Captulo 1
Introduc ao
Nas ultimas d ecadas, observou-se uma evoluc ao gradual das tecnologias da informac ao,
e como desdobramento desse evento, a organizac ao e o comportamento humano sofreram
modicac oes. Prova disso s ao os sistemas de compras pelas redes de computadores, que nos
ultimos tempos tiveram um crescimento acelerado. O Brasil, assim como outros pases pelo
mundo, possui v arios casos de sucesso de lojas de com ercio eletr onico (E-Commerce)
1
.
Esse fato se deve ` a comodidade de, a partir de um computador ligado ` a Internet, poder-se
realizar compras de bens e servicos. Nesse modelo, o usu ario tem a facilidade e a liberdade
de se usar o tempo que julgar necess ario para avaliar o produto que deseja adquirir, al em de
efetuar pesquisas em v arias lojas ao mesmo tempo.
Outro fator importante, est a na qualidade do atendimento, devido aos atendentes
possurem em m aos um sistema de informac ao para prover respostas ageis e credenciadas.
Assim, o usu ario economiza tempo e se exime de problemas naturais da organizac ao con-
tempor anea como: as las, gastos de deslocamento, tr ansito e estacionamento.
Al em disso, as lojas virtuais possuem sistemas de recomendac ao de produtos, que com
base no perl e nas aquisic oes habituais do usu ario, oferecem produtos incentivando o
usu ario a utilizar o E-Commerce. Todos esses benefcios s ao alguns dos fatores de sucesso
das maiores lojas de E-Commerce no Brasil e no mundo.
A Pesquisa sobre o Uso das Tecnologias de Informac ao e Comunicac ao no
Brasil/TIC Domiclios em 2009 ( ultima divulgada at e a data de nalizac ao desta
dissertac ao)[CETIC.br 2009], realizada pelo Centro de Estudos sobre as Tecnologias da
Informac ao e da Comunicac ao (CETIC.br)
2
e ao Comit e Gestor da Internet no Brasil
(CGI.br) mostrou que, de 2008 para 2009, houve um aumento de 8% na consulta a precos de
produtos ou servicos na Internet, passando de 44% para 52% em todo o Brasil, e que houve
um crescimento nas compras on line de 3%, passando de 16% para 19% nacionalmente. A
pesquisa ainda revela que, do total de domiclios pesquisados em 2009, 32% tinham compu-
1
www.americanas.com.br, www.submarino.com.br, www.pontofrio.com.br e outros
2
Vinculado ao N ucleo de Informac ao e Coordenac ao do Ponto BR (NIC.br)
1
tador (contra 25% em 2008) e 25% tinham acesso ` a Internet (contra 18% em 2008).
Assim os dados da pesquisa supracitada mostram que, no Brasil, as buscas por produtos
e servicos na Internet e crescente e que gradualmente mais pessoas t em acesso ao com ercio
eletr onico.
O com ercio eletr onico possui outros suportes al em do computador, tais como o celular
e, mais recentemente, a TV digital. A compra de produtos pela TV n ao e algo novo. Atual-
mente existem at e canais especcos para tal atividade, no entanto, o usu ario precisa utilizar
um outro canal para nalizar o processo de compra. A TV Digital traz a facilidade de permi-
tir que todo este processo seja iniciado e nalizado diretamente do controle remoto da TV,
trazendo mais comodidade para os usu arios, em uma modalidade denominada T-Commerce.
As possibilidades dos recursos de interatividade da TV Digital (TVD) s ao in umeras,
dependendo da criatividade das produtoras de conte udo e desenvolvedores de software. Um
dos sonhos atualmente possveis com as tecnologias de TVD e a compra de produtos que
estejam sendo exibidos em um programa de TV convencional, como um t enis, uma bolsa,
um quadro, ou qualquer outro.
Tendo em vista esta tend encia crescente de provimento de servicos nas mais diversas
plataformas e o sucesso de v arios servicos de com ercio eletr onico no Brasil e no mundo, a
presente dissertac ao descreve uma arquitetura para provimento de com ercio eletr onico pela
TV Digital (T-Commerce). A arquitetura proposta e composta por diversos servicos Web
que, juntos, agregam todos os servicos que s ao disponibilizados aos usu arios dos sistemas
de T-Commerce a serem desenvolvidos a partir de tal arquitetura. Esta arquitetura e ent ao
enquadrada como uma Arquitetura Orientada a Servicos (Service Oriented Architecture -
SOA), voltada para o provimento de servicos de T-Commerce.
Tal arquitetura foi elaborada devido n ao terem sido encontrados outros trabalhos que
tratem de uma proposta de com ercio eletr onico para a TV Digital. Assim, a proposta aqui
apresentada serve como base para o desenvolvimento de aplicac oes de T-Commerce, visando
a popularizac ao de servicos de com ercio eletr onico pelo Sistema Brasileiro de TV Digital.
Considerando que o sinal anal ogico de TV Digital est a previsto para ser desligado em 2016,
segundo previs ao do Minist erio das Comunicac oes
3
, todos os brasileiros que desejarem re-
ceber sinal de TV, precisar ao de um televisor com conversor integrado ou um conversor para
conectar ` a um televisor convencional. Desta forma, sistemas de T-Commerce podem ter um
grande alcance.
A arquitetura proposta, elaborada a partir de requisitos funcionais e n ao funcionais, serve
de base para a implementac ao de aplicativos para com ercio eletr onico, para o qual s ao
tamb em elicitados requisitos funcionais e n ao funcionais. Esses aplicativos s ao construdos
com base em um modelo de templates para denir a identidade visual da mesma, permitindo
que, ao ser alterado o template, toda a identidade visual da aplicac ao seja alterada.
3
http://goo.gl/nLVnW
2
A arquitetura e a aplicac ao de T-Commerce propostas utilizam Web Services para dispo-
nibilizar funcionalidades aos usu arios. Desta forma, tal proposta vai ao encontro da tamb em
crescente tend encia de integrac ao entre Web e TV. Tal integrac ao e possvel por meio de pro-
tocolos de comunicac ao padronizados, como o caso dos protocolos HTTP e SOAP, que neste
trabalho s ao objeto de implementac oes especcas.
Para esta integrac ao entre Web e TV, apresenta-se uma proposta de framework de
comunicac ao de dados que possibilita a comunicac ao entre aplicac oes de TV Digital e
servicos disponveis na Web, o qual tem seu emprego demonstrado n ao somente por meio de
aplicac oes de T-Commerce, mas tamb em de rastreamento de encomendas, leitor de RSS e
outras.
Um framework e um conjunto de classes que incorporam um projeto abstrato de soluc oes
para uma famlia de problemas relacionados[Johnson e Foote 1988]. O mesmo pode ser
tamb em denominado como arcabouco, estrutura, esqueleto, suporte e outros termos.
Alguns dos requisitos do aplicativo de T-Commerce supracitado s ao contemplados com
a extens ao do framework LuaOnTV para permitir o uso de temas e a adaptac ao autom atica
da interface de usu ario da aplicac ao para diferentes tamanhos de TV ou at e mesmo em dis-
positivos m oveis como telefones celulares.
1.1 Objetivos
1.1.1 Geral
Propor e desenvolver uma arquitetura orientada a servicos, por meio de Web Services
SOAP, para provimento de com ercio eletr onico pela TV Digital, favorecendo a converg encia
Web-TV.
1.1.2 Especcos
Como objetivos especcos, prop oe-se:
A) elicitar requisitos funcionais e n ao funcionais a serem atendidos por uma arquitetura
baseada em padr oes de servicos Web, a ser utilizada para com ercio eletr onico via TV
Digital;
B) propor uma arquitetura de servicos de T-Commerce, que atenda aos requisitos citados;
C) a partir da arquitetura , implementar um framework para comunicac ao de dados, baseado
nos protocolos HTTP e SOAP, para permitir a comunicac ao de aplicac oes de TV Digital,
desenvolvidas nas linguagens NCL e Lua, que permita a interoperac ao com servicos
Web;
3
D) caracterizar o emprego do framework de comunicac ao de dados para desenvolvimento
de aplicac oes tais como Leitor de RSS, Rastreador de Encomendas, Cliente de Twitter,
Enquete e Quiz;
E) estender o framework LuaOnTV[J unior e Gondim 2009] incluindo recursos de temas
para permitir a denic ao centralizada das caractersticas visuais das aplicac oes desen-
volvidas, al em de incluir suporte a m ultiplos dispositivos com diferentes resoluc oes de
tela, como TVs e aparelhos celulares;
F) um modelo de desenvolvimento de aplicac oes para TV Digital (TVD), de forma que
todos os formul arios da aplicac ao (p aginas/telas) tenham um mesmo conjunto de com-
ponentes b asicos, permitindo a criac ao de templates para denir a identidade visual da
mesma. Assim, ao ser alterado o template, toda a identidade visual da aplicac ao dever a
ser alterada;
4
1.2 Justicativa
Como o incio das operac oes do Sistema Brasileiro de TV Digital (SBTVD) e bastante
recente, onde a primeira transmiss ao de sinal digital foi realizada em 2007 na cidade de S ao
Paulo, at e a data de elaborac ao da presente dissertac ao, s o conhecia-se um caso de aplicac ao
de T-Commerce no Brasil, como citado em [Sntese 2010], no qual apenas exibem-se os
produtos e o processo de compra deve ser realizado pelo usu ario utilizando outro canal como
a loja virtual (Internet) ou o call center da empresa.
Al em disso, tal aplicac ao de com ercio eletr onico foi desenvolvida para o middleware
ByYou (implementac ao do Ginga desenvolvida pela empresa TOTVS)[TeleTime 2010], e seu
uso ca restrito aos conversores digitais e televisores que possuam tal middleware. Por usar
APIs especcas do ByYou, a aplicac ao s o executa em tal implementac ao do middleware
Ginga.
Como o Brasil possui diversos casos de sucesso no mercado de com ercio eletr onico em
larga escala, a disponibilizac ao de aplicac oes de com ercio para TV Digital e uma tend encia
natural, podendo aumentar consideravelmente as vendas das empresas do ramo, devido ` a
grande penetrac ao do aparelho de TV nos lares brasileiros (cerca de 96%)[IBGE 2009], al em
de ser uma nova plataforma de E-Commerce para os usu arios.
Da falta de uma arquitetura para provimento de com ercio eletr onico para o SBTVD,
surgiu este trabalho de dissertac ao, que apresenta uma proposta de arquitetura orientada a
servicos (Service Oriented Architecture - SOA) para a estruturac ao de um ambiente de T-
Commerce. Considerando que tal arquitetura e bastante utilizada para a integrac ao de siste-
mas heterog eneos, ele vai ao encontro de umdos objetivos do projeto: prover uma arquitetura
de T-Commerce que utilize servicos Web que, juntos, atuem de forma interoper avel com o
SBTVD e os padr oes W3C.
Desta forma, como a arquitetura SOA pode, comumente, ser baseada em Web Services
SOAP, faz-se necess aria a implementac ao de protocolos como Hypertext Transfer Protocol
(HTTP) e Simple Object Access Protocol (SOAP) em que se baseiam as tecnologias relacio-
nadas a SOA, sendo tais implementac oes objetivos principais deste trabalho.
Com a implementac ao dos protocolos HTTP e SOAP (onde n ao se tem conhecimento,
at e a data de elaborac ao desta dissertac ao, de nenhuma implementac ao de c odigo aberto
dos mesmos para o ambiente de TVD) criam-se enormes possibilidades de construc ao de
aplicac oes para integrac ao entre Web e TV, um dos objetivos deste projeto com sua arquite-
tura de T-Commerce. Como durante as pesquisas observou-se que a falta de implementac ao
de tais protocolos era uma queixa recorrente nos f oruns da Comunidade Ginga no Portal
do Software P ublico
4
e em outros f oruns de discuss ao, a implementac ao de tais protoco-
los representa uma grande contribuic ao para o desenvolvimento do SBTVD. Assim, ap os
a publicac ao inicial das implementac oes dos protocolos HTTP e SOAP, alguns trabalhos
4
http://www.softwarepublico.gov.br/dotlrn/clubs/ginga/
5
importantes foram desenvolvidos, como ser a apresentado no Captulo 5.
6
1.3 Metodologia
Para o desenvolvimento da presente dissertac ao foi feito um levantamento bibliogr aco
sobre as tecnologias, linguagens, ferramentas e trabalhos relacionados para nortear a
implementac ao da arquitetura e soluc ao proposta.
O projeto, an alise e desenvolvimento da soluc ao seguiu o processo de desenvolvimento
em cascata juntamente com o processo de componentizac ao[Sommerville 2011]. O processo
em cascata foi adotado pois os requisitos estavam bem denidos, havendo pequena probabi-
lidade de mudancas radicais. J a o processo de componentizac ao foi tamb em adotado devido
ao uso de alguns componentes reutiliz aveis (como Web Services pr oprios e de terceiros)
realizando a integrac ao destes diversos componentes.
No processo de desenvolvimento em cascata, foram seguidas as seguintes etapas:
especicac ao de requisitos - foram denidos os requisitos funcionais e n ao funcionais,
que s ao apresentados ao longo do trabalho;
projeto - foi adotado o paradigma de Orientac ao a Objetos (OO), utilizando-se a Uni-
ed Modeling Language (UML) para modelagem, com o auxlio de ferramenta CASE
(Computer-Aided Software Engineering);
implementac ao - a implementac ao seguiu o paradigma OO, conforme denido na fase
de projeto;
testes - foram feitos testes de interoperabilidade/integrac ao para vericar se os com-
ponentes da arquitetura estavam se comunicando conforme o esperado.
Optou-se, para o desenvolvimento do projeto, pelo paradigma de orientac ao a objetos
pois o mesmo permite um alto grau de reutilizac ao de c odigo, tornando o mesmo mais orga-
nizado e f acil de manter.
Para a comunicac ao entre os componentes da arquitetura da soluc ao, foi escolhido o pro-
tocolo de comunicac ao SOAP, uma vez que a aplicac ao de TV Digital desenvolvida faz parte
de uma arquitetura distribuda e precisa realizar comunicac ao com servidores Web por meio
da Internet. Assim, foi preciso usar um protocolo que n ao tivesse problemas de bloqueio em
rewalls. Desta forma, o protocolo SOAP foi escolhido tamb em por ser padr ao do World
Wide Web Consortium (W3C).
Para as aplicac oes de TV Digital, foi escolhido o sub-sistema Ginga-NCL do middleware
Ginga do Sistema Brasileiro de TV Digital (SBTVD), devido ` a grande quantidade de docu-
mentos, f oruns de discuss ao, ferramentas e exemplos disponveis em relac ao ` a outra vertente
de desenvolvimento utilizando a linguagem Java no sub-sistema Ginga-J. Considerando-se
ainda que o Ginga-NCL e o unico sub-sistema obrigat orio para dispositivos m oveis, isto foi
decisivo para a escolha, pois assim, a arquitetura e as aplicac oes desenvolvidas podem, em
7
tese, ser executadas em receptores (conversores/Set-bop Boxes) de TV Digital xos, m oveis
ou port ateis.
Com a escolha do Ginga-NCL, foi necess aria a implementac ao do protocolo SOAP para
este sub-sistema, utilizando-se a linguagem Lua, uma vez que o primeiro s o disponibiliza
protocolos at e a camada de transporte do modelo OSI/ISO, como o TCP. Com isto, foi ne-
cess ario realizar testes de interoperabilidade entre aplicac oes de TV Digital desenvolvidas
com as linguagens NCL e Lua e Web Services desenvolvidos em diferentes plataformas e
linguagens, pois um dos grandes benefcios do protocolo SOAP e a integrac ao de sistemas
heterog eneos. Assim, tais testes foram necess arios para garantir esta interoperabilidade.
Os requisitos da aplicac ao foram levantados tomando por base as funcionalidades exis-
tentes na grande maioria dos Web sites de com ercio eletr onico disponveis na Internet e
bastante difundidos no Brasil.
Para a construc ao da interface de usu ario das aplicac oes de TV Digital, optou-se pela
utilizac ao do framework LuaOnTV para abstrair as primitivas gr acas para renderizac ao
da interface. A mesma foi projetada baseada em recursos de templates, o que permite a
personalizac ao e adaptac ao autom atica para diferentes resoluc oes de tela, tendo sido esten-
dido o LuaOnTV para incluir tais recursos.
8
1.4 Organizac ao do Trabalho
O Captulo 2 apresenta uma revis ao bibliogr aca das tecnologias empregadas e relaci-
onadas ao desenvolvimento do trabalho.
O Captulo 3 apresenta a arquitetura de T-Commerce proposta.
O Captulo 4 apresenta o Framework LuaOnTV, utilizado na construc ao das interfaces
gr acas das aplicac oes desenvolvidas.
O Captulo 5 apresenta um framework de comunicac ao de dados, utilizado para a
integrac ao das aplicac oes desenvolvidas com servicos Web.
Por m, o Captulo 6 apresenta as conclus oes e trabalhos futuros.
9
Captulo 2
Revis ao bibliogr aca
2.1 Com ercio Eletr onico: E-Commerce, M-Commerce e T-
Commerce
No incio da World Wide Web (comumente denominada apenas Web) as primeiras
p aginas de Internet possuam apenas conte udo est atico permitindo pouca ou nenhuma
interac ao do usu ario. A Web era apenas um reposit orio de informac oes. Com a cres-
cente demanda de troca de informac oes entre empresas, o advento de padr oes abertos de
comunicac ao, e a necessidade das mesmas de alcancarem novos clientes e mercados, du-
rante a d ecada de 90 comecou a surgir um novo g enero de Web sites: os sites de com ercio
eletr onico[Chu et al. 2007].
Tais Web sites possibilitaram a realizac ao de neg ocios entre compradores e vende-
dores e entre vendedores e seus parceiros. Desta forma surgiu o E-Commerce. Este
e baseado na possibilidade de realizac ao de transac oes de forma eletr onica. Segundo
[Veijalainen, Terziyan e Tirri 2006]:
uma transac ao eletr onica e uma venda ou compra de produtos ou servicos, entre
empresas, familiares, indivduos, governos e outras organizac oes p ublicas ou
privadas, conduzidas por redes mediadas por computador.
A troca de informac oes entre essas empresas era feita por meio de Eletronic Data In-
terchange (EDI) (troca eletr onica de informac oes), no entanto, isto requeria realizac ao de
acordos entre as organizac oes[Chu et al. 2007], o que poderia dicultar tais parcerias. O ad-
vento de padr oes abertos como o XML permitiu a evoluc ao de tais processos de interc ambio
de dados e integrac ao entre empresas.
Atualmente existem diversas empresas consolidadas na area de com ercio eletr onico. Al-
gumas nasceram na era digital e vendem exclusivamente pela Internet, alcancando novos
clientes e mercados nacionais e internacionais.
10
Com a recente popularizac ao de dispositivos m oveis e da Internet sem o como rede
de grande abrang encia (por exemplo, utilizando as tecnologias de comunicac ao m ovel
de 3
a
gerac ao como o Universal Mobile Telecommunications System - UMTS), surgem
novas oportunidades para as lojas de com ercio eletr onico. Estas entram em uma nova
era, com novas perspectivas de captac ao de clientes e mercados. Com isto surgem no-
vas tend encias como o denominado Com ercio M ovel (M-Commerce), onde as transac oes
s ao feitas utilizando-se dispositivos e redes de acesso m oveis, tais como Wireless Local
Area Networks (WLANs), redes de telecomunicac oes 2G ou 3G, conex oes Bluetooth ou
infravermelho[Veijalainen, Terziyan e Tirri 2006].
Tais dispositivos m oveis permitem que os usu arios possam realizar compras em qualquer
lugar que eles estejam, at e mesmo em suas horas livres, durante o trajeto para o trabalho,
ou no hor ario de almoco. Desta forma, as lojas virtuais t em um mercado em potencial para
aumentar suas vendas.
Com o advento dos sistemas de televis ao digital interativa e a possibilidade de se ter apli-
cativos executando juntamente com a programac ao audio-visual, abre-se um novo mercado
para as lojas de com ercio eletr onico: a venda de produtos pela TV. Tais servicos de vendas
pela TV n ao s ao novos, mas antes da TV Digital Interativa (TVDi), os canais de venda pela
TV apenas anunciavam produtos e os telespectadores que desejavam comprar um produto
precisavam utilizar outro canal de comunicac ao, como o telefone ou recorrer ao Web site da
loja na Internet. Utilizando-se os recursos da TV Digital Interativa, todo o processo de com-
pra pode ser realizado diretamente pelo controle remoto da TV, desde que a mesma esteja
conectada ` a Internet.
As tecnologias da TV Digital trazem um novo benefcio aos usu arios: a possibilidade de
comprar produtos a partir de um receptor de TV Digital, caracterizando uma nova modali-
dade de com ercio eletr onico, denominada T-Commerce.
Em pases norte-americanos e europeus, que t em sistemas de TV Digital Interativa h a
mais tempo que o Brasil, existem algumas empresas disponibilizando soluc oes para a area
de T-Commerce
1 2 3
. No Brasil, apesar de as transmiss oes de TV Digital terem inici-
ado somente em 2007 na cidade de S ao Paulo[G1 2007], em 2010 j a h a soluc oes iniciais
para T-Commerce[Sntese 2010], apesar de a nalizac ao da compra ainda precisar ser feita
utilizando-se outros canais como o telefone.
Devido ao Brasil ser um pas de caractersticas bem diferentes dos outros pases, espera-
se que a interatividade seja um grande diferencial para o pas. Como o Governo Federal
pretende realizar inclus ao social/digital por meio da TV, de acordo com o Decreto n umero
4.901, de 26 de novembro de 2003, espera-se que a disponibilizac ao de servicos pela TV
seja crescente. Um fator importante para a difus ao da interatividade no pas e a exist encia
de aparelhos de TV em 96% das resid encias[IBGE 2009], tendo grandes possibilidades de
1
http://www.ensequence.com/t-commerce
2
http://www.digisoft.tv/applications.html
3
http://www.icuetv.com/ets_platform/applications/t_commerce
11
as aplicac oes interativas terem um enorme p ublico, considerando ainda as dimens oes con-
tinentais do Brasil e sua enorme populac ao de 185.712.713 habitantes, segundo o Censo
2010[IBGE 2010].
Outra medida tomada pelo governo que beneciar a a interatividade pela TV Digital e
a criac ao do Plano Nacional de Banda Larga (PNBL), por meio do Decreto n umero 7.175,
de 12 de maio de 2010, visando prover Internet banda larga, a um custo reduzido, em mu-
nicpios onde n ao exista tal servico.
2.2 Sistema Brasileiro de TV Digital (SBTVD)
O Sistema Brasileiro de TV Digital (SBTVD) atualmente e o mais avancado do mundo.
A necessidade de o Brasil implantar um sistema de TV Digital levou o Governo Federal a
emitir o Decreto 4.901, de 26 de novembro de 2003, instituindo o referido sistema.
A partir da, o governo passou a investir diretamente na pesquisa de tecnologias para
TV Digital. Considerando que j a havia outros padr oes de TV Digital no mundo, como o
americano ATSC (Advanced Television Systems Committee), o europeu DVB (Digital Video
Broadcast) e o japon es ISDB-T (Integrated Services Digital Broadcasting Terrestrial), tais
estudos concluram que o melhor para o pas seria a adoc ao do sistema japon es ISDB-T, que
seria estendido para atender ` as caractersticas e necessidades do Brasil.
Desta forma, o Decreto 5.820, de 29 de junho de 2006 estabelece o uso do ISDB-T como
base para o Sistema Brasileiro de TV Digital Terrestre (SBTVD-T). O decreto ainda dene
a criac ao do F orum SBTVD (F orum do Sistema Brasileiro de TV Digital). Tal f orum, como
menciona o decreto supracitado, tem como atribuic oes:
a assessoria acerca de polticas e assuntos t ecnicos referentes ` a aprovac ao
de inovac oes tecnol ogicas, especicac oes, desenvolvimento e implantac ao do
SBTVD-T.
O mesmo foi composto, como cita o decreto:
entre outros, por representantes do setor de radiodifus ao, do setor industrial e
da comunidade cientca e tecnol ogica
Dentre as contribuic oes do Brasil para a area de TVD, destaca-se a construc ao do Ginga
4
como padr ao de middleware para aplicac oes interativas e n ao interativas. O Ginga e uma
inovac ao nacional, atuando como respons avel pela execuc ao e controle do ciclo de vida das
3
http://www.forumsbtvd.org.br
4
http://www.ginga.org.br
12
aplicac oes interativas, abstraindo o sistema operacional e o hardware para elas, al em de rea-
lizar tarefas especializadas como a disponibilizac ao de Application Programming Interfaces
(APIs) para facilitar o desenvolvimento de aplicac oes interativas[Soares e Barbosa 2009].
O Ginga e composto por dois sub-sistemas: um para a execuc ao de aplicac oes decla-
rativas, denominado Ginga-NCL
5
, e outro para execuc ao de aplicac oes procedurais, de-
nominado Ginga-J
6
. Aplicac oes declarativas s ao aquelas implementadas utilizando-se uma
linguagem declarativa, como XML, de forma n ao algortmica, apenas declarando elemen-
tos que compor ao a mesma. Tais linguagens abstraem muitos detalhes do desenvolvedor.
Aplicac oes procedurais s ao aquelas implementadas utilizando uma linguagem procedural,
como Java, onde o desenvolvedor precisa escrever um algoritmo e especicar cada operac ao
a ser realizada, necessitando de conhecimento em linguagens de programac ao.
O sub-sistema Ginga-NCL permite a construc ao de aplicac oes declarativas por meio da
linguagem NCL, a Nested Context Language
7
. Esta e conhecida como uma linguagem de
cola, que permite criar aplicac oes declarativas juntando-se diferentes tipos de mdias como
imagens, texto, hipertexto (HTML), vdeos e outros. Um de seus principais recursos e a
sincronizac ao de mdias, muito importante no contexto de aplicac oes interativas. Tal recurso
garante que, por exemplo, uma legenda seja sincronizada com um vdeo em exibic ao, ou que
uma imagem apareca depois de determinado tempo que o vdeo iniciou. As aplicac oes NCL
podem ter seu poder estendido com a inclus ao de mdias especiais: os scripts Lua
8
, conheci-
dos em aplicac oes NCL como NCLua. Tais scripts adicionam caractersticas procedurais ` as
aplicac oes NCL.
O outro sub-sistema que comp oe o Ginga e o chamado Ginga-J, que permite a construc ao
de aplicac oes interativas utilizando a linguagem Java. Os outros padr oes de middleware de
TV Digital pelo mundo, na parte procedural, normalmente utilizam a linguagem Java e a
API JavaTV. No entanto, os fabricantes, para embarcarem a m aquina virtual Java e tal API
nos conversores de TV Digital precisam pagar royalities ` a Oracle, empresa que atualmente
det em os direitos sobre a marca Java. Com isto, o preco dos conversores e encarecido.
Al em disto, tal API e baseada no toolkit gr aco AWT, que e bastante antigo e n ao possui
componentes com visual bonito e elegante. Devido ` as quest oes de pagamento de royalities,
o F orum SBTVD decidiu fazer um acordo entre a ent ao Sun, hoje Oracle, para a denic ao
de uma nova API para ser utilizada pelo SBTVD, a qual foi batizada de JavaDTV
9
. Tal API
e livre de royalities e e baseada no toolkit gr aco LWUIT
10
, o Light Weight UI Toolkit. O
LWUIT e um toolkit que possui componentes bonitos e elegantes e e o mesmo utilizado em
aplicac oes para celulares.
Com as contribuic oes brasileiras, o ISDB-T e o SBTVD-T passaram a compartilhar
5
http://www.gingancl.org.br
6
http://dev.openginga.org
7
http://www.ncl.org.br
8
http://www.lua.org
9
http://www.forumsbtvd.org.br/materias.asp?id=75
10
http://lwuit.java.net
13
uma denominac ao internacionalmente conhecida como ISDB-TB, onde Brepresenta as
contribuic oes do Brasil para o ISDB-T[SBTVD 2010].
As melhorias resultantes da parceria realizada levaram o ISDB-TB a se tornar norma
internacional de TV Digital no ITU-T (International Telecommunications Union - Telecom-
munication Standardization Sector)[InfoExame 2009][IDGNow 2010]. O Ginga se tornou
padr ao de middleware para TVD, relativo ` a recomendac ao ITU-T J.200[ITU-T 2010]. Seu
sub-sistema declarativo Ginga-NCL se tornou recomendac ao ITU-T J.201[ITU-T 2009] e
seu sub-sistema imperativo Ginga-J se tornou recomendac ao ITU-T J.202[ITU-T 2010].
Ressalta-se, tamb em, a recente normatizac ao, no ambito do ITU-T, referente a IPTV,
conhecida como H.761, baseada fortemente no middleware Ginga e seu sub-sistema Ginga-
NCL. Desta forma, o Ginga pode chegar a novas plataformas que n ao apenas a TV aberta, e
as aplicac oes interativas e n ao interativas desenvolvidas em NCL/Lua para o SBTVD podem
tamb em ser executados em sistemas de IPTV que adotem o Ginga-NCL.
2.3 A Tecnologia de Web Services
H a alguns anos as aplicac oes corporativas eram desenvolvidas principalmente em um
modelo cliente/servidor de duas camadas, existindo uma aplicac ao desktop que fazia acesso
direto a um banco de dados. Pela natureza destas aplicac oes, que precisam ser instaladas
em cada computador onde ser ao executadas, existe um grande esforco para atualizar todos
os computadores com novas vers oes do sistema. Mesmo que haja um processo automati-
zado para esta atualizac ao, isto demanda recursos como tempo e largura de banda. Com o
avanco das tecnologias de comunicac ao de dados, o avanco da Web e suas linguagens de
programac ao e, principalmente, com o advento da tecnologia AJAX, atualmente e possvel
desenvolver aplicac oes de Internet ricas (Rich Internet Applications, RIA) com componen-
tes visuais que v ao al em dos componentes b asicos oferecidos pela linguagem HTML. Isto
permitiu que muitas empresas migrassem seus sistemas desktop para a plataforma Web, sem
perder funcionalidades existentes naquele tipo de interface.
Essa mudanca de paradigma desktop para Web vem seguida ainda de outra tend encia: a
dos sistemas distribudos. Estes s ao sistemas que comumente utilizam a arquitetura cliente/-
servidor, no entanto, s ao compostos de tr es ou mais camadas. Segundo [Sommerville 2011]:
um sistema distribudo e uma colec ao de computadores independentes que apa-
rece para o usu ario como um unico sistema coerente.
A Figura 2.1 apresenta uma arquitetura de um sistema distribudo em quatro camadas.
As mesmas s ao descritas a seguir.
Camada de Apresentac ao: pode contar tanto com aplicac oes desktop leves, conhecidas
como thin client (cliente magro/leve), possuindo apenas uma interface gr aca que faz
14
acesso a um servidor de aplicac ao, por meio de chamadas de procedimento remoto;
quanto com um browser, que faz acesso a um servidor Web, respons avel por gerar as
interfaces HTML.
Camada Web: composta por um ou mais servidores Web, respons aveis por gerar a
interface HTML para os clientes Web. As aplicac oes desktop n ao acessamesta camada,
tendo ligac ao direta com a Camada de Aplicac ao.
Camada de Aplicac ao: composta por um ou mais servidores de aplicac ao onde as re-
gras de neg ocios da aplicac ao est ao implementadas. Desta forma, alterac oes na l ogica
de neg ocios n ao requer a atualizac ao dos clientes. Os servidores de aplicac ao adicio-
nam toler ancia a falhas e balanceamento de cargo ao sistema.
Camada de Dados: composta por um ou mais servidores de banco de dados, acessveis
apenas pelos servidores de aplicac ao, o que garante transpar encia e independ encia de
banco de dados aos clientes.
Figura 2.1: Arquitetura de Aplicac ao Distribuda (adaptada de [InterSystems 2010]).
Segundo [Coulouris, Dollimore e Kindberg 2007], umsistema distribudo traz benefcios
como: permitir a heterogeneidade de componentes, possibilitar a escalabilidade, ser tolerante
a falhas, dentre outros.
15
Neste contexto, Web Services (WSs) proveem um framework extensvel para
comunicac ao de aplicac ao para aplicac ao, que utiliza protocolos Web existentes e base-
ados em padr oes XML abertos [Curbera et al. 2002]. Eles s ao a maior tecnologia para
publicac ao de servicos na Web e t em signicativa adoc ao em areas como integrac ao de
aplicac oes, computac ao distribuda de larga escala e cooperac ao business-to-business (B2B)
[KOPECK
Y e Simperl 2008]. Os mesmos s ao instalados na Camada de Aplicac ao, como

mostrado na Figura 2.1, e proveem um conjunto de padr oes para acesso a servicos pela In-
ternet, sendo uma tecnologia estabelecida no mercado e cada vez mais adotada por empresas
[Lausen e Haselwanter 2007].
Web Services permitem o desenvolvimento baseado em componentes, acessveis por
meio da Internet. Eles s ao componentes reutiliz aveis, que as aplicac oes, independente-
mente da linguagem em que foram implementadas, podem utilizar sem se preocupar em
como eles foram desenvolvidos [Vilas et al. 2007]. Desta forma, a construc ao de aplicac oes
a partir de Web Service segue o processo de desenvolvimento de software conhecido como
componentizac ao, como apresentado em [Sommerville 2011].
Diferentemente de tecnologias como Common Object Request Broker Architecture
(CORBA), Distributed Component Object Model (DCOM), Component Object Model Plus
(COM+) e Java Remote Method Invocation (RMI), WSs usam protocolos Web e formatos de
dados ubquos, como HTTP e XML [Vilas et al. 2007].
O objetivo dos Web Services e alcancar a interoperabilidade entre aplicac oes, usando
padr oes Web (Web standards). Eles usam um modelo de integrac ao fracamente acoplado
para permitir a integrac ao exvel de sistemas heterog eneos em uma variedade de domnios,
incluindo Business-to-Consumer (B2C), Business-to-Business (B2B) e Enterprise Applica-
tion Integration (EAI) [OASIS 2007].
Pela pr opria natureza distribuda da Web, o uso de WSs vem ao encontro da integrac ao
entre aplicac oes heterog eneas, executando em diferentes plataformas, desenvolvidas por di-
ferentes empresas. Cada vez mais empresas disponibilizam servicos, p ublicos ou privados,
para serem utilizados por terceiros, permitindo a interoperabilidade entre diferentes sistemas.
Al em disto, pelo fato de WSs serem transportados, principalmente, por protocolo HTTP, n ao
sofrem com problemas de portas bloqueadas em Firewalls que outras tecnologias, como as
mencionadas anteriormente, encontram. Isto facilita ainda mais a integrac ao entre sistemas
hospedados em diferentes redes.
Um framework de WSs pode ser dividido em tr es areas: protocolos de comunicac ao,
descric ao de servicos e descoberta de servicos [Sommerville 2011], conforme apresenta a
Figura 2.2 e as sub-sec oes seguintes.
16
Figura 2.2: Arquitetura conceitual de sistemas orientados a servicos (adaptada de
[Sommerville 2011]).
2.3.1 Protocolos de Comunicac ao
Dada a natureza distribuda e heterog enea da Web, mecanismos de comunicac ao devem
ser independentes de plataforma, seguros e leves quanto possvel. A linguagem XML e um
padr ao altamente utilizado para codicac ao e interc ambio de dados entre sistemas, sendo
totalmente independente de plataforma. Por esse motivo, a mesma e utilizada no protocolo
de comunicac ao usado por WSs.
O Simple Object Access Protocol (SOAP), e um protocolo padronizado pelo World Wide
Web Consortium (W3C), como protocolo de comunicac ao para WSs. O SOAP e um proto-
colo, baseado em XML, para a troca de mensagens e chamadas de procedimentos remotos
(Remote Procedure Call, RPC). No lugar de denir um novo protocolo para empacotar as
mensagens, SOAP utiliza protocolos Web existentes como HTTP e SMTP.
Ele e um protocolo leve, adequado para comunicac ao em um ambiente distribudo e
descentralizado [Vilas et al. 2007].
Uma mensagem SOAP, tamb em denominada envelope SOAP, e composta por um ar-
quivo XML, contendo um elemento header e um body. A Listagem 2.1 mostra a estrutura
de um envelope SOAP.
Listagem 2.1: Estrutura de um envelope SOAP [Curbera et al. 2002]
1 <SOAP: Envel ope
2 xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
3 <SOAP:Header>
4 <! c o n t e n t of header goes her e >
5 </ SOAP:Header>
6
7 <SOAP:Body>
8 <! c o n t e n t of body goes her e >
9 </ SOAP:Body>
10 </ SOAP: Envel ope>
17
2.3.1.1 Troca de Mensagens SOAP
Como exemplo para esta sec ao, vamos utilizar um sistema Web de uma companhia a erea,
como apresentado em [Curbera et al. 2002]. O sistema disponibiliza um Web Service (WS)
para a compra de passagens. Uma empresa que vende pacotes tursticos pode utilizar este
WS para integrar o seu sistema com o da companhia a erea, e assim, fazer todo o processo de
registro da passagem dentro do seu pr oprio sistema. Desta forma, o sistema da empresa de
turismo deve enviar um envelope SOAP para o WS disponibilizado pela companhia a erea,
contendo os dados do cliente e dados da passagem a ser adquirida, como data/hora, n umero
do voo e do assento escolhido pelo cliente. A Listagem 2.2 mostra um exemplo de tal
envelope SOAP, empacotado numa mensagem HTTP.
Listagem 2.2: Envelope SOAP transportado via HTTP [Curbera et al. 2002]
1 POST / t r a v e l s e r v i c e
2 SOAPAct i on: "http://www.acme-travel.com/checkin"
3 Cont ent Type: t e x t / xml ; c h a r s e t ="utf-8"
4 Cont ent Le ngt h: nnnn
5
6 <SOAP: Envel ope
8 <SOAP:Body>
9 <e t : e Ti c k e t x ml n s : e t =
10 "http://www.acme-travel.com/eticket/schema">
11 <et : pas s e nger Na me f i r s t ="Joe" l a s t ="Smith"/>
12 <e t : f l i g h t I n f o a i r l i ne Na me ="AA"
13 f l i ght Numbe r ="1111"
14 d e p a r t u r e Da t e ="2002-01-01"
15 de pa r t ur e Ti me ="1905"/>
16 </ e t : e Ti c k e t>
17 </ SOAP:Body>
Observe que o envelope SOAP da Listagem 2.2 n ao possui um header. O mesmo e
um elemento opcional e utilizado para prover informac oes especcas da aplicac ao, como
credenciais para acesso ao servico e informac oes de cobranca, dentre outras[Point 2010].
2.3.1.2 Chamadas de Procedimento Remoto Usando SOAP
Para que SOAP possa usar RPC para chamar procedimentos remotos, e necess ario espe-
cicar alguns detalhes para o protocolo RPC, por exemplo:
como valores de tipos s ao transportados entre a representac ao SOAP (XML) e a
representac ao da aplicac ao, e vice-versa (para indicar, por exemplo, como deve ser
feita a convers ao de uma classe Java para XML e vice-versa), e
18
onde as v arias partes do protocolo RPC s ao transportadas (identicac ao de objeto,
nome da operac ao e par ametros de entrada e sada).
A especicac ao XML schema do W3C
11
prov e uma linguagem padr ao para denir a
estrutura do documento e os tipos de dados da estrutura do XML. Isto e, dado um tipo b asico
como integer ou um tipo complexo como uma struct, XML schema oferece uma forma
padr ao de escrever dados destes tipos em um documento XML. Para habilitar o transporte de
valores tipados, SOAP assume um sistema de tipos baseado em XML schema e dene sua
codicac ao em XML. Usando este estilo de codicac ao pode-se produzir uma codicac ao
XML para qualquer tipo de dado estruturado. Par ametros RPC e retornos s ao especicados
usando esta codicac ao.
Usando o mesmo WS da companhia a erea, a empresa de turismo deseja obter
informac oes a respeito de um determinado voo. Assim, seu sistema pode enviar um en-
velope SOAP ao WS da companhia a erea. O envelope da Listagem 2.3 mostra uma chamada
RPC, encapsulada dentro de um envelope SOAP. O envelope permite a invocac ao do m etodo
remoto GetFlightInfo, que recebe dois par ametros: uma string contendo o nome da compa-
nhia a erea, e um inteiro contendo o n umero do voo. Tal m etodo retorna um valor estruturado
(uma struct) com dois campos: o n umero do port ao de embarque e a situac ao do voo.
No envelope SOAP, a chamada para GetFlightInfo e um elemento XML com atributos
que incluem informac oes sobre a codicac ao (note a refer encia para o XML schema). Os
elementos lhos s ao os argumentos do m etodo: airlineName e ightNumber. Os tipos s ao
denidos no atributo type, onde xsd refere-se as denic oes de um XML schema. Quando o
servidor SOAP recebe o envelope, ele converte os valores string, dos atributos airlineName e
ightNumber, para seus respectivos tipos string e inteiro, chamando o m etodo GetFlightInfo
passando estes valores.
Listagem 2.3: Chamada SOAP RPC empacotada em HTTP [Curbera et al. 2002]
1 POST / t r a v e l s e r v i c e
2 SOAPAct i on: "http://www.acme-travel.com/flightinfo"
5
6 <SOAP: Envel ope
8 <SOAP:Body>
9 <m: Ge t Fl i g h t I n f o
10 xml ns: m="http://www.acme-travel.com/flightinfo"
11 SOAP: encodi ngSt yl e ="http://schemas.xmlsoap.org/soap/encoding/"
12 xml ns : xs d="http://www.w3.org/2001/XMLSchema"
13 x ml n s : x s i ="http://www.w3.org/2001/XMLSchema-instance">
14 <a i r l i ne Na me x s i : t y p e ="xsd:string">UL</ a i r l i ne Na me>
15 <f l i ght Numbe r x s i : t y p e ="xsd:int">506</ f l i ght Numbe r>
11
http://www.w3.org/XML/Schema
19
16 </ m: Ge t Fl i g h t I n f o>
17 </ SOAP:Body>
A Listagem 2.4 mostra a resposta ` a requisic ao SOAP enviada anteriormente. Neste caso,
a resposta cont em um valor estruturado, com os campos gate (n umero do port ao de embar-
que) e status (situac ao do voo).
Implementac oes de SOAP existem para diversas linguagens, como C/C++, Java, Perl e
Lua
12
, que automaticamente geram e processam mensagens SOAP. Assumindo que as men-
sagens est ao em conformidade com as especicac oes do protocolo SOAP, elas podem ser tro-
cadas por servicos implementados em diferentes linguagens e plataformas, permitindo uma
total interoperabilidade entre sistemas heterog eneos, algo que n ao e sempre verdade para
sistemas que utilizam a arquitetura CORBA, que possui objetivos semelhantes ao SOAP.
Listagem 2.4: Resposta de requisic ao SOAP empacotada em HTTP [Curbera et al. 2002]
1 HTTP/ 1 . 1 200 OK
4
5 <SOAP: Envel ope
7 <SOAP:Body>
8 <m: Ge t Fl i ght I nf oRe s pons e
9 xml ns: m="http://www.acme-travel.com/flightinfo"
10 SOAP: encodi ngSt yl e ="http://schemas.xmlsoap.org/soap/encoding/"
11 xml ns : xs d="http://www.w3.org/2001/XMLSchema"
12 x ml n s : x s i ="http://www.w3.org/2001/XMLSchema-instance">
13 <f l i g h t I n f o>
14 <ga t e x s i : t y p e ="xsd:int">10</ ga t e>
15 <s t a t u s x s i : t y p e ="xsd:string">ON TIME</ s t a t u s>
16 </ f l i g h t I n f o>
17 </ m: Ge t Fl i ght I nf oRe s pons e>
18 </ SOAP:Body>
2.3.2 Descric ao de Servicos
O protocolo SOAP dene uma linguagem padr ao para uso de WSs, mas ele n ao informa
quais mensagens devem ser trocadas para que tenhamos sucesso no uso de um determinado
servico. Para isto, existe a Web Service Description Language (WSDL), uma linguagem
tamb em baseada em XML. Um documento WSDL descreve a interface de um WS, permi-
tindo que as aplicac oes que consumir ao o servico disponibilizado saibam quais informac oes
12
Uma implementac ao do protocolo SOAP foi feita para uso em aplicac oes de TV digital desenvolvidas em
NCL e Lua, e ser a apresentada no Captulo 5.
20
devem incluir dentro de um envelope SOAP, para chamar um determinado procedimento re-
moto, disponibilizado pelo WS. O WSDL descreve um WS como uma colec ao de end points
que podem trocar certas mensagens [Curbera et al. 2002]. Um end point e um elemento no
WSDL que dene a ligac ao entre a denic ao de um determinado servico e o seu endereco de
rede, permitindo o acesso ao mesmo.
As mensagens SOAP anteriormente mostradas n ao poderiam ter sido construdas se
n ao conhec essemos o documento WSDL que descreve o servico que desejamos utilizar.
Informac oes como o nome do m etodo a ser acessado e o nome e tipos dos par ametros de
entrada e sada foram obtidos a partir do WSDL do servico [Curbera et al. 2002].
Um servico completo de descric ao WSDL prov e dois pedacos de informac ao: uma
descric ao do servico em nvel de aplicac ao, ou interface abstrata, e detalhes especcos de-
pendentes do protocolo, que os usu arios devem seguir para acessar o servico em end points
concretos [Curbera et al. 2002].
2.3.2.1 Descric ao de um Web Service
Um documento WSDL dene uma descric ao abstrata de um servico, em termos de troca
de mensagens em uma interac ao com o mesmo. Existem tr es principais componentes desta
interface abstrata: o vocabul ario, a mensagem e a interac ao. Acordo para uso de um determi-
nado vocabul ario e a fundac ao para qualquer tipo de comunicac ao. Um WSDL usa sistemas
de tipos externos para prover denic ao de tipos de dados para troca de informac oes. Embora
o WSDL possa suportar qualquer sistema de tipos, a maioria dos servicos usa o XML Schema
Denition (XSD). Na Listagem 2.5, podemos ver o uso de dois tipos de dados denidos no
XSD (int e string), e dois tipos de dados denidos em um schema externo (FlightInfoType e
Ticket). O WSDL pode importar tais denic oes XSD externas usando um elemento import,
especicando sua localizac ao [Curbera et al. 2002].
O WSDL dene elementos message contendo partes, cada qual descrita por tipos XSD
ou elementos de um vocabul ario pr e-denido. Cada message prov e uma denic ao de dados
tipados e abstratos enviados e recebidos pelos servicos. Uma mensagem pode ser de entrada
(input), denindo o tipo do(s) par ametro(s) que uma determinada func ao deve receber; ou de
sada (output), indicando o(s) tipo(s) de valor(es) a ser(em) retornado(s) pela func ao, como
pode ser visto na Listagem 2.5 [Curbera et al. 2002].
Os elementos portType e operation combinam mensagens para denir iterac oes. Cada
operation representa um padr ao de troca de mensagens suportado pelo WS. Cada operation
e uma combinac ao de mensagens rotuladas como input (entrada), output (sada) ou fault
(falha), para indicar o papel de cada mensagem em uma iterac ao [Curbera et al. 2002].
Um portType e uma colec ao de operac oes que s ao coletivamente suportadas por um end
point (port). No exemplo da Listagem 2.5, AirportServicePortType descreve duas operac oes:
uma unica operac ao no estilo request-response, GetFlightInfo, que espera uma mensagem
21
GetFlightInfoInput como entrada e retorna uma mensagem GetFlightInfoOutput como res-
posta; e uma operac ao uni direcional, CheckIn, que apenas recebe uma mensagem CheckI-
nInput como entrada [Curbera et al. 2002].
Listagem 2.5: Fragmento de uma descric ao de WSDL [Curbera et al. 2002]
1 <message name="GetFlightInfoInput">
2 
3 
4 </ message>
5
6 <message name="GetFlightInfoOutput">
7 
8 </ message>
9
10 <message name="CheckInInput">
11 
12 </ message>
13
14 <por t Type name="AirportServicePortType">
15 <o p e r a t i o n name="GetFlightInfo">
16 
17 <out put message="tns:GetFlightInfoOutput"/>
18 </ o p e r a t i o n>
19 <o p e r a t i o n name="CheckIn">
20 
21 </ o p e r a t i o n>
22 </ por t Type>
2.3.2.2 Informac oes de Binding
A especicac ao do WSDL apresenta tr es tipos de informac oes sobre o
servico[Sommerville 2011]:
quais operac oes o servico suporta (chamado de interface);
como mapear as interfaces abstratas para um conjunto de protocolos concretos (bin-
ding), e
onde est a a implementac ao dos m etodos suportados pelo servico (o endereco de rede).
Por meio do binding temos a resposta para o como, incluindo o protocolo de
comunicac ao e especicac ao de formato de dados para um completo elemento portType.
Sucintamente, o elemento binding diz como dada interac ao ocorre sobre o protocolo espe-
cicado. A Listagem 2.6 mostra um fragmento para o exemplo citado. O binding descreve
como usar SOAP para acessar o servico travelservice. Em particular, o documento WSDL
mostra que:
22
GetFlightInfo usar a interac oes em estilo SOAP-RPC, em que todas as trocas de men-
sagens usam codicac ao padr ao SOAP, e
CheckIn e uma interac ao de mensagem pura (chamada de orientada a documento em
termos de WSDL), em que o corpo do envelope SOAP cont em a mensagem codicada,
sem nenhuma codicac ao de tipo adicional; isto e, ele usa XSD para literalmente
descrever o XML transmitido.
O restante do documento descreve o onde, para ligar a interface abstrata, protocolo e
detalhes de marshalling
13
, promovendo a ligac ao (binding) desses elementos para permitir o
acesso aos m etodos do servico. Um elemento port descreve um unico end point como uma
combinac ao de um binding e um endereco de rede. Consequentemente, um elemento service
pode agrupar um conjunto de ports relacionados.
Listagem 2.6: Informac oes concretas de ligac ao em um WSDL [Curbera et al. 2002]
1 <bi ndi ng name="AirportServiceSoapBinding"
2 t ype ="tns:AirportServicePortType">
3 <s o a p : b i n d i n g
4 t r a n s p o r t ="http://schemas.xmlsoap.org/soap/http"/>
5 <o p e r a t i o n name="GetFlightInfo">
6 <s o a p : o p e r a t i o n s t y l e ="rpc"
7 s oapAct i on ="http://acme-travel/flightinfo"/>
8 
9 <s oap: body use ="encoded"
10 namespace="http://acme-travel.com/flightinfo"
11 e nc odi ngSt yl e =
12 "http://schemas.xmlsoap.org/soap/encoding/"/>
13 
14 <out put>
15 <s oap: body use ="encoded"
16 namespace="http://acme-travel.com/flightinfo"
17 e nc odi ngSt yl e =
18 "http://schemas.xmlsoap.org/soap/encoding/"/>
19 </ out put>
20 </ o p e r a t i o n>
21
22 <o p e r a t i o n name="CheckIn">
23 <s o a p : o p e r a t i o n s t y l e ="document"
24 s oapAct i on ="http://acme-travel.com/checkin"/>
25 
26 <s oap: body use ="literal"/>
27 
28 </ o p e r a t i o n>
29 </ bi ndi ng>
30
13
Processo de organizar dados emcomputador, de forma padronizada, para permitir que diferentes aplicac oes
possam utilizar tais dados, garantindo a interoperabilidade.
23
31 <s e r v i c e name="travelservice">
32 
34 <s o a p : a d d r e s s
35 l o c a t i o n ="http://acmetravel.com/travelservice"/>
36 
37 </ s e r v i c e>
A Figura 2.3 mostra como a especicac ao do WSDL e organizada. A sec ao Introduc ao
do WSDL cont em a declarac ao dos Namespaces XML contendo as denic oes de tipos
padr oes usados pelo Web Service. A sec ao Interface Abstrata apresenta os tipos deni-
dos pelo Web Service, as declarac oes de interfaces (os portTypes) e as mensagens suportadas
(como mensagens com os par ametros de entrada a serem enviadas a um m etodo no Web Ser-
vice e as mensagens de sada com o retorno do m etodo). A sec ao Implementac ao Concreta
cont em as informac oes de binding (como o protocolo a ser utilizado na troca de mensagens)
e os end points (as interfaces concretas para realizac ao da vinculac ao da aplicac ao cliente
com o endereco de rede do Web Service.
Figura 2.3: Organizac ao da Especicac ao do WSDL[Sommerville 2011].
2.3.2.3 Usando o WSDL
Para usu arios e desenvolvedores, o WSDL prov e uma descric ao formal das interac oes
cliente/servidor. Desenvolvedores podem usar o documento WSDL como entrada para uma
aplicac ao que gere func oes proxy
14
, utilizadas no cliente, para acesso aos m etodos do WS.
Tais func oes proxy tamb em podem ser geradas dinamicamente, em tempo de execuc ao, por
rotinas implementadas no cliente que interpretam o WSDL e geram as chamadas SOAP
necess arias. Em ambos os casos, as func oes proxy t em a nalidade de esconder do cliente
toda a complexidade envolvida no processo de chamada dos m etodos remotos.
14
Tais func oes proxy s ao escritas ou geradas na linguagem utilizada pela aplicac ao cliente (que consome
o Web Service) e possuem a mesma assinatura dos m etodos remotos, tornando transparente para o cliente a
chamada aos m etodos no WS, sendo respons aveis por gerar o envelope SOAP para enviar ao servidor onde o
WS e hospedado.
24
2.3.3 Descoberta de Servicos com UDDI
As especicac oes do Universal Description, Discovery and Integration (UDDI) ofere-
cem aos usu arios uma forma sistem atica e unicada para encontrar provedores de servicos
atrav es de um registro centralizado de servicos, que e, grosseiramente, equivalente a uma
lista telef onicaautomatizada online de WSs [Curbera et al. 2002]. O UDDI Business Re-
gistry (UBR), acessvel por meio de um browser, foi disponibilizado pouco tempo ap os
a especicac ao se tornar p ublica, no entanto, o mesmo foi descontinuado em 2005
15
[Treiber e Dustdar 2007].
Segundo [Sommerville 2011], o padr ao UDDI n ao foi amplamente adotado. UDDI prov e
dois tipos b asicos de especicac ao que denem a estrutura e operac ao do registro de servicos
[Curbera et al. 2002]:
uma denic ao da informac ao para prover sobre cada servico, e como codic a-la; e
uma API de busca e atualizac ao para o registro, que descreve como esta informac ao
pode ser acessada e atualizada.
O acesso ao registro e realizado usando uma API SOAP para busca e atualizac ao.
2.3.4 Web Services REST
Como visto anteriormente, SOAP e o padr ao W3C para Web Services, amplamente uti-
lizado na integrac ao de aplicac oes heterog eneas. No entanto, existe uma outra vertente para
construc ao de Web Services denominada REST. O REST e o acr onimo para Representational
State Transfer. Ele e um estilo arquitetural para construc ao de aplicac oes distribudas que
tamb em permite a integrac ao de aplicac oes heterog eneas, mas n ao e um padr ao W3C.
O estilo REST foi apresentado pela primeira vez no trabalho de dissertac ao de Roy
Fielding[Fielding 2000], sendo baseado em padr oes Web como HTTP e URL. Ele consiste
em prover servicos Web a partir de um recurso Web acessvel por meio de uma URL. A
interac ao com tal servico e feita por meio de uso dos m etodos HTTP como GET, POST e
DELETE para passagem de par ametros ao servico. Tal estilo e bastante simplicado em
relac ao ao SOAP, pois todos os dados a serem passados ao servico v ao diretamente na URL
do mesmo, por meio de uma requisic ao HTTP. Desta forma, o tamanho de uma requisic ao
REST e bastante reduzido em relac ao ao SOAP.
REST n ao dene um padr ao de formato das mensagens de resposta, no entanto, pode-
se perfeitamente utilizar XML para isto. Atualmente outros padr oes de formato de dados
s ao bastante utilizados como o JavaScript Object Notation (JSON). Desta forma, pode-se
utilizar qualquer padr ao que se desejar, como por exemplo, o formato de dados denido pela
15
http://uddi.microsoft.com/about/FAQshutdown.htm
25
linguagem Lua, sendo bastante util em aplicac oes para o Sistema Brasileiro de TV Digital,
desenvolvidas em tal linguagem, por utilizar um formato nativo da mesma.
O estilo REST atualmente se tornou um padr ao de fato e e amplamente utilizado para
integrac ao de servicos Web com aplicac oes de diferentes tipos, como e o caso dos servicos
disponibilizados pelo microblog Twitter. Este permite que desenvolvedores construam
aplicac oes nas mais diferentes plataformas (Web, desktop, mobile) que se integrem com o
servico de microblog.
O REST tamb em segue a arquitetura cliente/servidor usada no protocolo SOAP. Segundo
[Welling 2006], o estilo e denominado REST (em portugu es, Transfer encia de Estado Repre-
sentacional), pois o cliente obt em uma representac ao de um recurso atrav es de uma URL, o
que faz com que a aplicac ao cliente entre em um determinado estado. O cliente pode sele-
cionar um link que foi includo no primeiro recurso para, por exemplo, obter informac oes
detalhadas. Como o link direciona para outro recurso, a aplicac ao cliente obt em uma nova
representac ao de um recurso e entra em um novo estado.
Como citado, a grande vantagem do REST e sua simplicidade, no entanto, por n ao haver
um padr ao de passagem de par ametros e formato de dados para a respostas das requisic oes,
tal estilo pode n ao ser adequado para a construc ao de aplicac oes seguindo o padr ao de ar-
quitetura orientada a servicos, onde uma aplicac ao pode utilizar servicos de diferentes pro-
vedores. Usando REST, cada provedor de servicos pode denir sua forma de passar os
par ametros e o formato de dados da mensagem de retorno, assim a aplicac ao que integra
com todos os provedores precisar a implementar diversos formatos de entrada e sada de da-
dos. Com o SOAP isto n ao ocorre, pois todos os provedores seguem um padr ao bem denido
e a aplicac ao cliente implementa apenas tal padr ao.
2.3.5 Arquitetura Orientada a Servicos
Segundo [Sommerville 2011], uma arquitetura orientada a servicos (Service Oriented
Architecture - SOA) e uma forma de desenvolvimento de sistemas distribudos onde os com-
ponentes de tal sistema s ao servicos stand-alone (aut onomos), executando em computadores
geogracamente distribudos. Em tal arquitetura, ainda segundo [Sommerville 2011], usar
Web Services e uma forma de as organizac oes tornarem suas informac oes acessveis. Com
isto, e possvel haver a integrac ao entre empresas, mesmo que por meio de sistemas hete-
rog enos completamente diferentes.
26
Captulo 3
Arquitetura de com ercio eletr onico para
a TV Digital
Neste captulo e apresentada uma arquitetura para provimento de com ercio eletr onico
para o Sistema Brasileiro de TV Digital. A mesma e uma arquitetura distribuda, baseada
em componentes reutiliz aveis, os Web Services, conhecida como Arquitetura Orientada a
Servicos.
Desta forma, a arquitetura proposta foi denida, incluindo a implementac ao de um fra-
mework de comunicac ao (baseado nos protocolos HTTP e SOAP) que e apresentado sucin-
tamente neste captulo, e em mais detalhes no Captulo 5.
3.1 Requisitos da Arquitetura
A arquitetura dever a atender aos requisitos apresentados na Tabela 3.1 a seguir.
27
Requisito Funcional N ao funcional
T-01) Estar preparada para adaptac ao em qualquer equipa-
mento com qualquer implementac ao do middleware Ginga,
seja para dispositivos xos (como conversores digitais e
TVs com conversores integrados), m oveis (como Notebo-
oks) ou port ateis (como telefones celulares).
x
T-02) Utilizar, preferencialmente, servicos gratuitos da
Web.
x
T-03) Facilitar o desenvolvimento de aplicac oes interativas
para o SBTVD, inclusive com relac ao ao tratamento de re-
cursos de interface gr aca.
x
T-04) Tornar transparente para a aplicac ao de TVD os pro-
vedores de servicos utilizados, permitindo a substituic ao
por outros apenas estendendo-se classes na aplicac ao cli-
ente e implementando a comunicac ao SOAP/HTTP com os
provedores desejados.
x
T-05) Facilitar a extens ao e a manutenc ao das aplicac oes
com uso de orientac ao a objetos e padr oes de projetos.
x
T-06) Fazer interoperac ao com servicos de forma amig avel
a rewalls.
x
T-07) Integrar diferentes servicos para compor as funciona-
lidades a seremdisponibilizadas aos usu arios das aplicac oes
de TVDi.
x
T-08) Ser compatvel com padr oes W3C e ABNT (Ginga-
NCL)
x
Tabela 3.1: Requisitos da Arquitetura de T-Commerce
3.2 Apresentac ao Geral
A arquitetura proposta e baseada no conceito de Service Oriented Architecture (SOA),
ou Arquitetura Orientada a Servicos, onde a aplicac ao e construda de forma distribuda,
utilizando diferentes Web Services, podendo haver diferentes provedores de servicos, que e
o caso da proposta implementada.
Uma arquitetura de com ercio eletr onico considera, comumente, o conceito de loja vir-
tual, que precisa integrar diferentes servicos para prover as funcionalidades necess arias aos
usu arios e ao gerenciamento da mesma. Em uma aplicac ao de T-Commerce n ao e diferente,
o que muda e apenas a plataforma, tendo-se uma interface gr aca de usu ario especca para
a TV Digital, considerando-se todas as quest oes de usabilidade como uso de fontes maiores
28
devido ao usu ario car afastado do aparelho de TV e de integrac ao Web-TV referentes a esta
plataforma. Todos os servicos que a loja virtual j a disponibiliza precisam ser acessados pela
interface de TV Digital. Desta forma, a arquitetura orientada a servicos vem ao encontro
dessa necessidade, permitindo a integrac ao de uma aplicac ao cliente em uma plataforma di-
ferente, possuindo uma interface gr aca para TV Digital, com os servicos j a implementados
pela loja.
SOA permite a integrac ao de sistemas hetererog eneos por utilizar a tecnologia de Web
Services SOAP que, diferentemente do modelo REST, dene um contrato unico que todos
os provedores e consumidores de servicos devem seguir (o protocolo SOAP), o que facilita
a integrac ao de tais sistemas.
Assim, para atender aos requisitos citados, a Figura 3.1 apresenta a arquitetura proposta.
Cada item da mesma e apresentado nas subsec oes a seguir, em que se adotam as seguin-
tes convenc oes: as letras representam os elementos de hardware ou provedores de servico,
e os n umeros representam os elementos de software (apenas os softwares aplicativos s ao
apresentados em tal gura).
Adicionalmente, embora n ao constando da Figura 3.1 (para dar uma vis ao mais sim-
ples inicialmente), os seguintes softwares s ao empregados (os quais s ao apresentados nos
captulos seguintes):
Framework LuaOnTV 2.0;
e Framework de Comunicac ao de Dados.
29
Figura 3.1: Vis ao Geral da Arquitetura SOA proposta para T-Commerce
A) Conversor Digital/Set-top Box (STB)
Conversor digital, televisor com conversor integrado contendo o middleware Ginga, onde
ser ao executadas as aplicac oes de TVDigital Interativa. Tais aplicac oes s ao conhecidas como
Thin Client (Clientes Leves/Magros)[Sommerville 2011] por apenas conterem uma camada
de apresentac ao, todas (ou grande parte) das regras de neg ocio s ao processadas no lado
servidor.
Visando experimentos futuros, considera-se o uso de notebooks ou telefones celulares
com implementac oes de Ginga-NCL para teste das aplicac oes desenvolvidas.
Tais equipamentos ser ao denominados daqui por diante como receptor/equipamento de
TVD.
B) E-Commerce WS
Web Services contendo as rotinas utilizadas em uma loja virtual convencional na Internet,
que ser ao utilizadas pela aplicac ao de TV Digital para prover com ercio eletr onico pela TV.
Tais Web Services encapsulam todas as regras de neg ocio para o gerencimento da loja virtual,
como rotinas de cadastro de clientes, produtos, pedidos, etc. A aplicac ao de TV Digital
consumir a tal Web Service para prover muitas das funcionalidades disponveis aos usu arios.
O uso de tais Web Services e essencial para centralizar as regras de neg ocio utilizadas
tanto pela aplicac ao de E-Commerce (normalmente acessada a partir de computadores ou
dispositivos m oveis como aparelhos celulares) como pela aplicac ao de T-Commerce (aces-
sada a partir de receptores de TVD).
C) SMS Gateway
O Gateway SMS e utilizado como intermedi ario para comunicac ao via SMS da loja com
o cliente. Devido ` a arquitetura proposta ser baseada em Web Services, o uso do Gateway
facilita tal integrac ao com a rede de telefonia celular.
Um servico implementado na aplicac ao de T-Commerce que requer o uso de SMS e a
recuperac ao de senha, permitindo que o usu ario que esqueceu a senha, receba a mesma via
mensagem SMS no telefone celular que estiver cadastrado na loja. Tais servicos n ao s ao
gratuitos e cobram por cada SMS enviado.
O uso do Gateway SMS e essencial por tornar transparente para a aplicac ao qual a ope-
radora sendo utilizada para enviar as mensagens SMS. Um das formas de envio de SMS
e utilizando softwares especcos para determinados aparelhos celulares. No entanto, para
automatizar tal processo seria necess ario fazer a integrac ao com tal software por meio de
30
alguma API, normalmente especca do software. O uso do Gateway dispensa tal complexi-
dade.
D) WS Preco e Prazo Sedex
Na arquitetura proposta, considerou-se que as entregas da loja sejam feitas pela Empresa
Brasileira de Correios e Tel egrafos (ECT), denominada daqui em diante simplesmente como
Correios. Desta forma, a obtenc ao de precos, prazos de rastreamento das encomendas utiliza
recursos dos Correios. Desta forma, o uso de umWeb Service dos Correios facilita a obtenc ao
de tais dados a partir de qualquer aplicac ao.
E) WS Rastreador de Encomendas
Ap os o cliente ter decidido realizar a compra e naliz a-la, apesar de j a saber previamente
qual a previs ao para a entrega do produto, um recurso muito utilizado e o rastreamento
online da encomenda. Para tal funcionalidade, pelo fato de estarem sendo usados os servicos
de logstica dos Correios, o rastreador de encomendas para TV Digital realiza o rastreamento
online de encomendas postadas por tal empresa.
F) WS Busca CEP
A busca de endereco a partir de um C odigo de Enderecamento Postal (CEP) e um requi-
sito fundamental para a aplicac ao de TVD, devido ao fato de o usu ario normalmente possuir
apenas o controle remoto para entrada de dados, utilizando o mesmo da mesma forma como
entra dados em um telefone celular. Desta forma, a aplicac ao de T-Commerce precisa reduzir
ao m aximo a quantidade de dados que o usu ario deve digitar, para agilizar tal processo tedi-
oso de entrada de dados. Na arquitetura proposta foi utilizado um Web Service para prover
tal funcionalidade.
G) Servidor SMTP
Como a aplicac ao de T-Commerce possui recurso de recuperac ao de senha tamb em por
e-mail, a arquitetura proposta inclui um servidor de Simple Mail Transfer Protocol (SMTP).
Tal servidor e tamb em conhecido como Mail Transfer Agent (MTA), que e respons avel por
transferir mensagens de correio eletr onico entre um computador e outro. Por meio de tal
servidor, a aplicac ao de TVD pode, por exemplo enviar a senha do usu ario para seu e-mail
ou conrmar a realizac ao de uma compra.
31
H) SMS Server
Os Gateways SMS fazem a integrac ao com o SMS Server de alguma(s) operadora(s)
para permitir o envio das mensagens SMS. Logo, o SMS Server e o respons avel direto pelo
envio das mensagens SMS pela rede de telefonia celular. Desta forma, o Gateway apenas se
encarrega de fazer a integrac ao com o(s) servidor(es) de SMS, tornando tranparente para a
aplicac ao esta comunicac ao com o terminal celular do usu ario.
3.2.1 Casos de Uso das Funcionalidades da Arquitetura
Para dar uma vis ao geral das funcionalidades providas pela arquitetura, tanto para os
desenvolvedores de aplicac oes de TV Digital Interativa (TVDi), quanto para os usu arios
nais, s ao apresentados os diagramas de casos de uso a seguir.
Figura 3.2: Diagrama de Casos de Uso das Funcionalidades providas a desenvolvedores de
aplicac oes TVDi
A Figura 3.2 apresenta as funcionalidades que a arquitetura prov e aos desenvolvedores
de aplicac oes de TVDi, por meio dos frameworks utilizados. Tais funcionalidades permitem
um grande aumento de produtividade no desenvolvimento de tais aplicac oes, reduzindo a
quantidade de c odigo que os desenvolvedores precisam escrever e, consequentemente, o
total de bugs
1
.
1
Erro no funcionamento de um software
32
Figura 3.3: Diagrama de Casos de Uso das Funcionalidades providas aos usu arios das
aplicac oes de TVDi desenvolvidas
A Figura 3.3 apresenta as funcionalidades que a arquitetura prov e aos usu arios de
aplicac oes de TVDi. As funcionalidades implementadas s ao as consideradas mais comuns
em sistemas de E-Commerce tradicionais.
3.2.2 Tecnologias Core da Arquitetura Proposta
Em [Chu et al. 2007] s ao tratadas as tecnologias core para o provimento de com ercio
eletr onico, divididas em quatro camadas: comunicac ao, apresentac ao e representac ao de
informac oes, linguagens, e armazenamento e recuperac ao de dados.
A camada de comunicac ao conta com as tecnologias necess arias para estabelecer a
comunicac ao entre as partes envolvidas nos sistemas de com ercio eletr onico, assim como
os protocolos utilizados para garantir a interoperabilidade entre as aplicac oes que comp oem
tais sistemas. Utilizam-se, na arquitetura aqui proposta, as tecnologias Hyper Text Transfer
Protocol (HTTP), Simple Object Access Protocol (SOAP), Simple Mail Transfer Protocol
(SMTP) e Short Message Service (SMS).
A camada de apresentac ao e representac ao de informac oes cont em as tecnologias que
denem o formato das informac oes, utilizado tanto para apresentac ao como para garantir a
troca de informac oes entre sistemas heterog enos. Utilizam-se, na arquitetura aqui proposta,
as tecnologias eXtensible Markup Language (XML), Really Simple Syndication (RSS), Lua,
e imagens Joint Photographic Experts Group (JPEG) e Portable Network Graphics (PNG).
As linguagens de programac ao s ao utilizadas para a construc ao das regras de neg ocio das
aplicac oes, denindo toda a l ogica das rotinas a serem executadas por elas. S ao utilizadas as
linguagens Java, Nested Context Language (NCL) e Lua.
A camada de armazenamento e recuperac ao de dados e respons avel pelo armazenamento
local ou remoto dos dados das aplicac oes, como Sistemas Gerenciadores de Bancos de Da-
dos (SGBDs). S ao utilizadas as tecnologias MySQL DataBase Management System, Java
Database Connectivity (JDBC) e Structured Query Language (SQL).
33
Figura 3.4: Tecnologias Core da arquitetura de T-Commerce (adaptada de [Chu et al. 2007]).
A Figura 3.4 apresenta as tecnologias empregadas na arquitetura proposta, em cada uma
das camadas supracitadas.
3.3 Descric ao dos Componentes de Software da Arquite-
tura
Conforme a Figura 3.1 exibida anteriormente, nesta sec ao s ao apresentados os softwares
aplicativos que comp oem a arquitetura.
A) Set-top Box
A.1) Aplicac ao de T-Commerce
A aplicac ao e a interface gr aca pela qual o usu ario pode realizar compras por meio da
TV Digital.
Os requisitos funcionais da aplicac ao foram baseados em avaliac ao emprica das funci-
onalidades existentes na maioria dos sistemas de E-Commerce disponveis no Brasil e am-
plamente conhecidos e utilizados. A Tabela 3.2 apresenta os requisitos funcionais e n ao
funcionais atendidas pela aplicac ao.
34
Requisito Funcional N ao Funcional
A.1-01) Permitir a exibic ao de produtos em destaque ao iniciar a aplicac ao X
A.1-02) Realizar a busca de produtos pelo ttulo parcial X
A.1-03) Adicionar produtos ao carrinho de compras X
A.1-04) Remover produtos do carrinho de compras X
A.1-05) Cadastrar v arios enderecos, permitindo ao usu ario escolher um endereco de entrega a
partir da lista de enderecos cadastrados
X
A.1-06) Permitir m ultiplas formas de pagamento, possibilitando ao usu ario selecionar uma das
formas suportadas
X
A.1-07) Cadastrar usu ario X
A.1-08) Realizar login de usu ario utilizando e-mail ou CPF X
A.1-09) Buscar endereco a partir do CEP X
A.1-10) Recuperar senha por e-mail e SMS X
A.1-11) Rastrear automatizadamente encomendas postadas pelos Correios, exibindo ao usu ario
informac oes sempre que a situac ao da encomenda mudar
X
A.1-12) Exibir preco e prazo de entrega, baseado em Web Services dos Correios X
A.1-13) Realizar processo de compra em etapas, permitindo que o usu ario volte a uma etapa ante-
rior, antes de nalizar a compra, para alterar algum dado (como mudar a forma de pagamento)
X
A.1-14) Utilizar bot oes coloridos do controle remoto para o acionamento da maioria das func oes
da aplicac ao
X
A.1-15) Processar grande parte das regras de neg ocio nos servidores Web que integram a arquite-
tura, desonerando o conversor digital da maior parte da carga de processamento, considerando que
o mesmo e um dispositivo de recursos restritos
X
A.1-16) Armazenar dos dados do carrinho de compras em mem oria RAM at e a nalizac ao da
compra, quando estes dados s ao enviados ao Web Service para registro da mesma
X
A.1-17) Carregar din amicamente a lista de produtos a partir do Web Service X
A.1-18) Permitir a exibic ao de comunicados, ofertas de produtos e promoc oes X
Tabela 3.2: Requisitos funcionais e n ao funcionais da aplicac ao de T-Commerce
A aplicac ao e apenas um cliente que consome os Web Services utilizados na arquitetura.
Assim, a maior parte da carga de processamento e regras de neg ocio e feita nos servidores
Web que hospedam os servicos. Quase todas as telas da aplicac ao (que podemos chamar
tamb em de formul arios ou p aginas) fazem acesso a algum Web Service para obtenc ao ou
registro de dados. Desta forma, a aplicac ao e totalmente dependente de um canal de inte-
ratividade (tamb em conhecido como canal de retorno) para conex ao ` a Internet e acesso aos
servidores Web que hospedam os servicos.
Como o telespectador pode visualizar e comprar qualquer produto existente na loja, e n ao
somente aqueles que estejam em destaque, para a exibic ao dos produtos sempre e feita uma
consulta ao Web Service de E-Commerce da loja. Em outros modelos de aplicac ao, como o
apresentado em [Sntese 2010], que exibem apenas os produtos em destaque, o telespectador
n ao precisa ter a TV conectada ` a Internet, pois ele s o visualiza os produtos enviados pela
emissora, e n ao pode nalizar o processo de compra pela TV. Desta forma, n ao h a necessi-
dade de conex ao com a Internet. A arquitetura proposta vai al em deste modelo, permitindo
que o usu ario possa comprar qualquer produto e nalizar a compra direto da TV, o que exige
a exist encia de um canal de interatividade.
A interface gr aca da aplicac ao foi desenvolvida utilizando-se uma nova vers ao do fra-
mework LuaOnTV[J unior e Gondim 2009], cujas melhorias foram desenvolvidas no pre-
sente trabalho de dissertac ao e s ao apresentadas em detalhes no Captulo 4. O LuaOnTV
e a primeira e, at e o momento em que esta dissertac ao foi desenvolvida, a unica biblioteca de
35
componentes NCLua para criac ao de interfaces gr acas em aplicac oes de TV Digital para o
Ginga-NCL que se tem conhecimento.
Um screenshot
2
da aplicac ao e apresentado na Figura 3.5. Tal gura mostra a tela inicial
da aplicac ao, com os produtos em destaque na loja virtual (denidos no banco de dados
da loja). O usu ario pode localizar um produto a partir de uma palavra contida no ttulo,
inserindo tal valor por meio do controle remoto. O ap endice no nal da dissertac ao mostra
screenshots de todas as telas da aplicac ao.
Figura 3.5: Aplicac ao de T-Commerce: Tela inicial mostrando os produtos em destaque
Toda a comunicac ao com os servicos que comp oem a arquitetura e feita por meio
do protocolo SOAP, utilizando-se a implementac ao de SOAP para o Ginga-NCL denomi-
nada NCLua SOAP, construda neste trabalho de dissertac ao e apresentada em detalhes no
Captulo 5.
O processo de compra na aplicac ao de T-Commerce desenvolvida e bastante simples e
direto. O diagrama de sequ encia apresentado na Figura 3.6 mostra como tal processo ocorre.
2
Imagem capturada de uma tela de determinada aplicac ao em execuc ao
36
Figura 3.6: Aplicac ao de T-Commerce: Diagrama de sequ encia do processo de compra
A.2) NCLua RSS Reader
Como pode ser visto na Figura 3.1, o Set-top Box (TV, notebook ou celular com o mid-
dleware Ginga) armazena a aplicac ao de T-Commerce al em de um leitor de RSS desenvolvi-
dos com as linguagens NCL e Lua.
Um arquivo RSS possui um formato XML e e utilizado para divulgac ao de notcias na
Internet, permitindo aos usu arios assinarem os chamados feeds RSS para obterem as notcias
de um determinado provedor desejado. Os feeds s ao os arquivos RSS que cont em as notcias
em formato XML. Com o RSS, a notcia vai at e o usu ario, no lugar de ele ir at e a notcia.
Assim, tendo umleitor de RSS, o usu ario pode adicionar v arios feeds e receber v arias notcias
de diferentes provedores.
O leitor de RSS implementado para a TV Digital nesta dissertac ao e denominado NCLua
37
RSS Reader
3
. Ele implementa o padr ao RSS 2.0[Board 2009] e comp oe a arquitetura de
T-Commerce para permitir que, quando o usu ario n ao estiver acessando a aplicac ao da loja
virtual pela TV, ele possa car atualizado com as promoc oes que a loja esteja divulgando.
A aplicac ao utiliza o m odulo LuaXML
4
(que foi estendido para funcionar com Lua 5).
Este e um parser XML escrito completamente em Lua, que permite obter as notcias do feed
RSS e exibir em um equipamento de TVD. A aplicac ao utiliza o m odulo NCLua HTTP para
fazer o download do arquivo RSS diretamente do site do provedor de conte udo, neste caso o
servidor Web da loja virtual. O NCLua HTTP ser a apresentado no Captulo 5. O NCLua RSS
Reader ainda utiliza o m odulo canvas de NCLua para desenho da interface gr aca, al em do
m odulo event para tratamento de eventos.
A Figura 3.7 apresenta um screenshot da aplicac ao de leitura de RSS em execuc ao, mos-
trando a mesma sendo exibida sobre o vdeo principal da emissora (em um ambiente simu-
lado, o Ginga Virtual Set-top Box).
Figura 3.7: NCLua RSS Reader - Leitor de Notcias para TV Digital
3
http://ncluarss.manoelcampos.com e http://labtvdi.unb.br
4
http://lua-users.org/wiki/LuaXml
38
A.3) Rastreador de Encomendas para TVD
Orastreador de encomendas para a TVDigital faz acesso a este Web Service desenvolvido
para o Ginga-NCL, utilizando as linguagens NCL e Lua e o m odulo NCLua SOAP, este a
ser apresentado no Captulo 5.
As Figuras 3.8 e 3.9 apresentam screenshots da aplicac ao em execuc ao. Tal aplicac ao,
juntamente com o m odulo NCLua SOAP, foi ganhadora do Concurso Latino-Americano de
Conte udo para TV Digital Interativa
5
, na categoria Widgets, realizado pela PUC-Rio em
2010.
Figura 3.8: Rastreamento de encomendas pela TVD: Inserc ao do c odigo de rastreamento
5
http://clube.ncl.org.br/node/82
39
Figura 3.9: Rastreamento de encomendas pela TVD: Situac ao da entrega da encomenda
(atualizada automaticamente a cada 5 minutos)
B) E-Commerce WS
O E-Commerce WS cont em um conjunto de Web Services desenvolvidos utilizando-se
o IDE NetBeans 6.7.1 e a Java API for XML Web Services (JAX-WS) com o servidor de
aplicac oes Glass Fish 2.1 para execuc ao dos Web Services. Tais ferramentas foram escolhi-
das por serem livres e multiplataforma, amplamente utilizadas no mercado para o desenvol-
vimento de aplicac oes, e pela familiaridade com as mesmas. O servidor de aplicac oes pode
ser qualquer outro (como Tomcat, Jetty ou JBoss) que implemente a especicac ao de Servlet
2.5. Um Servlet e uma classe Java server side, ou seja, que executa do lado do servidor Web,
sendo capaz de responder a requisic oes HTTP com resposta em formato (X)HTML, XML
e outros. A escolha pelo Glass Fish veio devido ao fato de ele ser a atual implementac ao
de refer encia para a plataforma Java Enterprise Edition (Java EE), que prov e as tecnologias
para desenvolvimento de aplicac oes Web em Java.
Os m etodos desenvolvidos em cada Web Service foram implementados, baseado em um
levantamento de requisitos do que deve ter uma loja virtual, como j a apresentado na Tabela
3.2. Utilizou-se a linguagem UML para modelar as classes e m etodos que comporiam os
servicos.
A Figura 3.10 apresenta um diagrama de classes com os Web Services implementados e
seus respectivos m etodos.
40
Figura 3.10: Diagrama de Classes dos Web Services implementados
Cada Web Service agrupa funcionalidades comuns. O Clientes, por exemplo, prov e
todas as funcionalidades para gerenciamento do cadastro do cliente, o Compras, todo o
processo de compra, o Produtos, todo o cadastro de produtos.
Estes Web Services publicam os m etodos a serem acessados pela aplicac ao de T-
Commerce. Os mesmos s ao respons aveis pelo gerenciamento de todos os dados armaze-
nados pela loja (como produtos, clientes e pedidos de compra). Eles utilizam as classes Java
apresentadas na Figura 3.11 como base para seus m etodos.
Tais classes s ao respons aveis pelo gerenciamento do cadastro do cliente, cadastro de
produtos, formas de pagamento, compras e tipo de frete. Para o armazenamento destes dados
foi utilizado o Sistema Gerenciador de Banco de Dados (SGBD) MySQL 5.1 por ser um
sistema multiplataforma, livre, bastante leve, que n ao requer muitos recursos de hardware
e amplamente utilizado no mercado, al em da familiaridade com o mesmo. No entanto, a
arquitetura pode utilizar qualquer outro banco de dados que for desejado, pois o acesso aos
dados e feito por meio da API Java Database Connectivity (JDBC) que e compatvel com
diversos SGBDs existentes no mercado. Al em disto, foi utilizado o padr ao de projeto Data
Access Objects (DAO) que permite fazer uma separac ao total entre as classes de neg ocio e
as instruc oes SQL para acesso ao banco de dados.
41
Figura 3.11: Diagrama das classes utilizadas internamente pelos WSs implementados
Os Web Services n ao utilizam nenhum framework de persist encia por falta de familia-
ridade com tais tecnologias e restric oes de tempo. No entanto, a utilizac ao de algum fra-
mework como Hibernate ou Java Persistent API (JPA) n ao altera em nada a comunicac ao
entre a aplicac ao de TVD e os Web Services. Tal mudanca arquitetural pode ser feita para
42
aumentar o nvel de abstrac ao do acesso ao banco de dados e automatizar a gerac ao das
instruc oes SQL necess arias para isto, sob pena de aumentar o overhead de acesso aos dados.
C) SMS Gateway
Para a arquitetura proposta, foi utilizado o Gateway MyTalk
6
, que permite o acesso via
Web Services SOAP. Contudo, tal componente pode ser substitudo na arquitetura por qual-
quer outro Gateway SMS. Todos os gateways encontrados e testados, disponibilizam acesso
via SOAP ou REST. A escolha de tal servico foi feita por ter sido o primeiro encontrado,
mas reitera-se que qualquer outro pode ser utilizado, levando-se em considerac ao custo, re-
sili encia, QoS (como tempo de resposta), etc.
Caso o usu ario esqueca sua senha, ele pode informar seu e-mail ou CPF na aplicac ao de
TVD e recuper a-la via e-mail ou SMS. Como ele normalmente estar a na frente da TV, sair
deste local para ir at e um computador e entrar no seu e-mail para pegar uma nova senha e
bastante inc omodo. Como o celular e algo pessoal e que geralmente as pessoas o mant em
por perto o tempo todo, o usu ario pode receber a nova senha sem precisar sair da frente da
TV, facilitando o processo de compra.
Neste caso, optou-se por a aplicac ao de TV enviar a requisic ao diretamente ao Gateway
SMS, no lugar de requisitar ao Web Service da loja (E-Commerce WS) para depois este
despachar a requisic ao ao Gateway SMS, no intuito de reduzir o tempo de resposta para a
aplicac ao de T-Commerce. No entanto, esta abordagem tem a desvantagem de vincular a
aplicac ao a um determinado Gateway SMS. Caso escolha-se utilizar um Gateway diferente,
a aplicac ao precisar a ser atualizada. Centralizando tal regra de neg ocio no Web Service da
loja, n ao haver a tal problema, mas aumentar a o tempo de resposta da requisic ao que precisar a
ser encaminhada ao Gateway.
D) WS Preco e Prazo Sedex
Um dos recursos b asicos que toda loja virtual deve prover a seus usu arios e informar
o preco e prazo para entrega do produto. Tals informac oes podem ser decisivas para a
concretizac ao ou n ao da compra.
Os Correios s ao respons aveis por grande parte das entregas de produtos e corres-
pond encias em todo o pas. Desta forma, a arquitetura de T-Commerce proposta faz
integrac ao com o Web Service dos Correios
7
que permite calcular o preco e prazo de en-
trega de uma correspond encia/produto de/para qualquer lugar do pas. Logo, a aplicac ao de
T-Commerce consegue exibir o preco e prazo para entrega do(s) produto(s) que o usu ario
deseja comprar, acessando tal Web Service.
6
http://www.mytalk.com.br
7
http://www.correios.com.br/webservices/
43
A atual vers ao da proposta permite apenas calcular preco e prazo de entrega de enco-
mendas utilizando o servico de entregas r apidas dos Correios, denominado Sedex, mas a
obtenc ao de informac oes de entrega para outros servicos dos Correios pode ser feita facil-
mente a partir da implementac ao atual.
A Figura 3.12 apresenta quais informac oes podem ser obtidas do Web Service dos Cor-
reios.
Figura 3.12: Web Service dos Correios: Calculando preco e prazo de entrega de encomenda
(fonte: http://www.correios.com.br/webservices/).
O acesso ao servico e feito a partir do E-Commerce WS apresentado na Sec ao 3.2. Assim,
a aplicac ao de T-Commerce em NCLua envia uma requisic ao ao Web Service Comprasque
possui o m etodo calcularSedexque retorna as informac oes sobre preco e prazo de entrega,
como apresentado no diagrama de classes da Figura 3.10.
E) WS Rastreador de Encomendas
Os Correios possuem um servico na Internet que permite ao usu ario saber a situac ao da
entrega de uma determinada encomenda, a partir do c odigo de rastreamento da mesma.
No entanto, o usu ario, para car atualizado da situac ao, precisa periodicamente acessar
tal p agina, gastando tempo que ele poderia utilizar em outras atividades mais importantes.
44
Assim, na arquitetura proposta, decidiu-se implementar um servico automatizado para
rastreamento de encomendas, onde o usu ario possa acessar o servico e deixar a tela do
mesmo aberta, sem precisar interagir com ela ou car voltando l a para vericar se a situac ao
da encomenda mudou. Uma vez tendo aberta a tela do servico, o usu ario ser a automatica-
mente noticado por meio de uma mensagem sonora, que a situac ao da encomenda mudou.
O servico est a disponvel via Web
8
e foi tamb em implementado em uma aplicac ao de TV
Digital para o Ginga-NCL.
Como os Correios n ao disponibilizam tal servico de rastreamento por meio de um Web
Service, para facilitar a integrac ao do servico em diferentes arquiteturas, foi desenvolvido
um Web Service para o rastreador. Este e respons avel por fazer o parse do c odigo HTML da
p agina do servico dos Correios e obter as informac oes sobre o rastreamento da encomenda.
Tais informac oes s ao extradas e retornadas pelo Web Service de forma estruturada, permi-
tindo a exibic ao delas facilmente em qualquer aplicac ao em diferentes plataformas. Um
exemplo e a aplicac ao iComenda
9
, desenvolvida por Maurcio J unior
10
, para os dispositivos
m oveis iPhone, iPod e iPad, a partir do Web Service disponibilizado.
F) WS Busca CEP
Infelizmente os Correios n ao disponibilizam um Web Service para a consulta de
enderecos a partir de um n umero de CEP. S o h a disponvel uma p agina Web para usu arios
nais
11
que retorna os dados do endereco como uma imagem, para impedir (ou pelo menos
dicultar bastante) que aplicac oes consigam acessar a p agina e extrair tais dados. Tal atitude
provavelmente e devida ao fato de os Correios terem um software comercial, denominado
Guia Postal Brasileiro Eletr onico
12
, contendo um banco de dados de CEPs, que e vendido
na sua loja virtual e nas ag encias.
No entanto, existem alguns Web Services de terceiros que permitem obter o endereco a
partir de umCEP. Qualquer umdeste servicos pode ser utilizado na arquitetura implementada
para permitir a obtenc ao de enderecos.
Para a implementac ao realizada, foi escolhido o Web Service disponvel em http://
www.maniezo.com.br/webservice/soap-server.php, por ter sido o primeiro
a ser encontrado. Tal servico requer a realizac ao de um cadastro pr evio para poder acess a-lo,
e com os poucos testes realizados, retornou os enderecos corretos e atualizados.
A aplicac ao de T-Commerce faz acesso direto a tal servico para obter um endereco,
utilizando-se o m odulo NCLua SOAP.
8
http://rastreador.manoelcampos.com e http://labtvdi.unb.br
9
http://itunes.apple.com/br/app/icomenda/id412358490?mt=8
10
http://mauriciojunior.org
11
http://www.buscacep.correios.com.br
12
http://www.correios.com.br/servicos/cep/gpbe.cfm
45
G) Servidor SMTP
Para envio de e-mail, a aplicac ao de T-Commerce acessa o m etodo sendMail do Web
Service Clientesdo E-Commerce WS, apresentado na Sec ao 3.2 e na Figura 3.10, para
enviar e-mail ao cliente. Desta forma, a aplicac ao cliente n ao acessa diretamente o servidor
de e-mail. O E-Commerce WS e que faz esta integrac ao, despachando a requisic ao para o
servidor SMTP.
O E-Commerce WS utiliza a API Java Mail, funcionando como um cliente SMTP para
despachar a mensagem de e-mail. Ele torna transparente para a aplicac ao, o servidor de
e-mail utilizado e as congurac oes para acesso ao mesmo.
Na implementac ao feita, foi utilizado umservidor de e-mail disponibilizado por umplano
de hospedagem prossional, logo e um servico com custo mensal. No entanto, pode-se utili-
zar qualquer servidor de e-mail que desejar, como por exemplo um que seja disponibilizado
por servicos de WebMail gratuitos, amplamente difundidos na Internet e usados no cotidiano.
3.4 Diagrama de Distribuic ao/Implantac ao
A Figura 3.13 apresenta um diagrama de distribuic ao/implantac ao que mostra como os
componentes da arquitetura, apresentados na Sec ao 3.2 s ao distribudos em diversos hardwa-
res, mostrando a arquitetura distribuda montada e a relac ao de depend encia entre cada com-
ponente. Tal diagrama apresenta todos os componentes de hardware e software da arquite-
tura proposta, incluindo os softwares aplicativos e os frameworks implementados.
Figura 3.13: Arquitetura de T-Commerce: Diagrama de Distribuic ao/Implantac ao
46
As funcionalidades de cada componente s ao resumidas a seguir:
A) Set-top Box - Conversor de TV Digital, TV com conversor integrado, notebook ou celular
que executa as aplicac oes de TVD desenvolvidas:
1 - Aplicac ao T-Commerce: aplicac ao de com ercio eletr onico para TVD (aplicac ao
cliente);
2 - NCLua RSS Reader: leitor de notcias para TVD, utilizado para ver notcias e
ofertas de produtos; da loja virtual;
3 - Rastreador de Encomendas para TVD: permite ao usu ario rastrear a entrega
do(s) produto(s) comprado(s) por meio da TV Digital, sendo noticado sempre que
a situac ao da encomenda mudar;
4 - NCLua SOAP: m odulo para acesso a Web Services SOAP em aplicac oes NCLua
para TVD;
5 - NCLua HTTP: m odulo que implementa o protocolo HTTP, utilizado pelo
NCLua SOAP e por aplicac oes como o NCLua RSS Reader. O m odulo e apre-
sentado no Captulo 5;
6 - LuaOnTV 2.0: framework para construc ao da interface gr aca da aplicac ao de
T-Commerce.
B) E-Commerce Host - Servidor Web que hospeda os Web Services a serem utilizados pela
aplicac ao de T-Commerce:
7 - ECommerceWS: Web Services da loja virtual, implementados em Java com a
API JAX-WS;
8 - DB Connection Pool: pool de conex oes ao banco de dados, implementado uti-
lizando a API JDBC, que permite que conex oes ao banco de dados sejam compar-
tilhadas entre diferentes requisic ao ao Web Service, possibilitando um aumento de
performance no acesso aos dados;
9 - RSS File: arquivo RSS contendo as notcias e ofertas de produtos a serem divul-
gados pela loja virtual;
10 - Database: banco de dados MySQL Server 5.1 que armazena todos os dados da
loja virtual, como cadastro de clientes, produtos e pedidos de compra.
C) SMS Gateway - Gateway para envio de mensagens SMS aos clientes:
11 - mytalk.com.br: Host que hospeda o servico MyTalk SMS, um Gateway para
envio de mensagens SMS.
D) Correios Host - Host dos correios que hospeda Web Services como os para consulta de
preco e prazo de entrega de encomendas:
47
12 - ws.correios.com.br: Web Services dos Correios para consulta de preco e prazo
de entrega de encomendas.
E) Rastreador Host - Host que armazena o servico de rastreamento de encomendas postadas
pelos Correios:
13 - rastreador.manoelcampos.com: Web Service de rastreamento de encomendas.
F) CEP WS Host - Host que hospeda um dos servicos de busca de endereco a partir do CEP:
14 - CEP WS: Web Service maniezo.com.br que fornece o endereco a partir de um
CEP
G) SMTP Host - Host que hospeda servidor de e-mail:
15 - SMTP Server: Servidor de e-mail para envio de mensagens eletr onicas aos
clientes da loja virtual.
H) SMS Server - Host de uma operadora de telefonia celular, respons avel pela comunicac ao
via SMS com o terminal celular do usu ario.
3.5 Ambiente de desenvolvimento
Para o desenvolvimento do projeto foram utilizados:
sistema operacional GNU/Linux Ubuntu 10.10 como sistema desktop para realizac ao
das tarefas de desenvolvimento;
Astah Community 6.1 (antigo Jude) para modelagem UML;
soapUI 3.5.1 para testes de consumo de Web Services SOAP;
IDE Eclipse 3.6 para desenvolvimento de aplicac ao Ginga-NCL:
plugin NCLEclipse 1.5.1;
plugin LuaEclipse 1.3.1;
ferramenta LuaDoc
13
para gerac ao de documentac ao;
implementac ao de refer encia do Ginga-NCL (Ginga Virtual Set-top Box 0.11.2);
interpretador Lua para execuc ao do scripts fora do Ginga Virtual Set-top Box;
XVidCap 1.1.7 para captura de screencasts
14
da aplicac ao em execuc ao;
13
http://luadoc.luaforge.net
14
Vdeo mostrando a execuc ao de determinada aplicac ao
48
IDE NetBeans 6.7.1 para modelagem UML e desenvolvimento dos Web Services da
loja virtual, utilizando API JAX-WS; servidor de aplicac oes Glass Fish 2.1 para
execuc ao dos Web Services da loja virtual
15
;
Java Development Kit (JDK) 1.6.0.24, o kit de desenvolvimento Java, contendo APIs
e ferramentas para desenvolvimento de aplicac oes;
Java Runtime Environment (JRE) 1.6.0.24, o ambiente de execuc ao Java para execuc ao
das aplicac oes Java como os Web Services criados, os IDEs e outras ferramentas de-
senvolvidas em Java como o soapUI;
MySQL Server 5.1 como Sistema Gerenciador de Banco de Dados (SGBD) para os
Web Services da loja virtual;
PhpMyAdmin para administrac ao do banco de dados;
PHP 5.3 e Apache 2 para execuc ao do PhpMyAdmin;
VirtualBox 4.0 e RemasterSys para criac ao de distribuic ao Linux contendo todo o am-
biente de desenvolvimento, com todas as ferramentas apresentadas acima.
3.6 Distribuic ao GNU/Linux para desenvolvimento,
execuc ao e teste de aplicac oes de TV Digital
Combase no trabalho apresentado em[Monteiro et al. 2010], foi gerada uma distribuic ao
GNU/Linux contendo todo o ambiente de desenvolvimento necess ario para a construc ao das
aplicac oes apresentadas ao longo deste trabalho. O ambiente cont em todas as ferramentas
apresentadas em 3.5. Tal distribuic ao GNU/Linux foi elaborada com o intuito de facilitar
a montagem do ambiente de desenvolvimento necess ario para a construc ao de aplicac oes
NCL/Lua para a TV Digital.
A comunidade Ginga no Portal do Software P ublico disponibiliza uma implementac ao
de refer encia do sub-sistema Ginga-NCL em forma de uma m aquina virtual j a com tal
implementac ao compilada e instalada. Tal m aquina virtual facilita bastante a montagem do
ambiente de desenvolvimento, uma vez que o processo de compilac ao de tal implementac ao
e bastante extenso, dependendo de diversos softwares e bibliotecas, n ao sendo um processo
trivial de ser executado, principalmente para usu arios menos experientes com distribuic oes
GNU/Linux e ferramentas de compilac ao de linha de comando. No entanto, o uso de uma
m aquina virtual adiciona um overhead de tempo no processo de teste das aplicac oes, uma
vez que os arquivos das mesmas precisam ser enviados via SSH para a m aquina virtual,
apesar de tal processo ser automatizado com o plugin NCL Eclipse.
15
http://java.net/projects/openesb
49
Desta forma, a instalac ao da implementac ao de refer encia do Ginga-NCL diretamente no
sistema operacional utilizado pelo desenvolvedor para as suas tarefas rotineiras (como envio
de e-mails, elaborac ao de documentos em suites de escrit orios, etc) e de desenvolvimento
de sistemas agiliza bastante o processo de execuc ao e teste das aplicac oes interativas, pois,
como o Ginga e instalado localmente na m aquina real, n ao h a processo de transfer encia de
arquivos para poder executar as aplicac oes. Com isto, a execuc ao das aplicac oes e pratica-
mente instant anea, al em de obter-se melhor desempenho executando o Ginga nativamente no
sistema operacional da m aquina real, uma vez que o uso de uma m aquina virtual obviamente
requer o consumo de mais mem oria RAM e processador que executar o Ginga nativamente
em uma m aquina real.
A distribuic ao desenvolvida foi baseada na vers ao 10.10 do Ubuntu e permite o uso
do ambiente de desenvolvimento sem a necessidade de instalac ao do mesmo na m aquina
do desenvolvedor, podendo ser dado boot na m aquina por meio de um CD contendo tal
distribuic ao, conhecido como Live CD. Ela pode ser instalada em uma m aquina real, onde
o usu ario poder a utilizar tal distribuic ao como seu sistema operacional Desktop para a
realizac ao de suas tarefas rotineiras e de desenvolvimento e ainda pode ser instalada em
uma m aquina virtual, j a com o ambiente gr aco e todas as ferramentas de desenvolvimento
necess arias.
A vers ao da implementac ao de refer encia do Ginga-NCL embarcada na distribuic ao e a
ultima (at e a data de entrega de tal dissertac ao), a 0.11.2 revis ao 23, disponvel na Comuni-
dade Ginga do Portal do Software P ublico
16
.
O processo de criac ao da distribuic ao GNU/Linux consistiu basicamente em:
instalar distribuic ao Ubuntu 10.10 em uma m aquina virtual utilizando a ferramenta
Virtual Box 4.0;
baixar e compilar a implementac ao de refer encia do Ginga-NCL em tal m aquina vir-
tual, juntamente com todas suas depend encais;
instalar ferramentas de desenvolvimento e suas depend encias (como JDK e JRE);
congurar ferramentas de desenvolvimento para permitir a execuc ao local de
aplicac oes NCL/Lua;
gerar uma nova distribuic ao a partir do ambiente criado, j a com todas as ferramentas
instaladas, utilizando o software RemasterSys
17
.
Tal distribuic ao pode ser obtida pelo site do Laborat orio de TV Digital Interativa da
Universidade de Braslia
18
.
16
http://svn.softwarepublico.gov.br/trac/ginga/wiki/Building_Wiki_
GingaNCL
17
http://remastersys.sourceforge.net
18
http://labtvdi.unb.br
50
Captulo 4
Framework LuaOnTV 2.0
Atendendo ao requisito T3) Facilitar o desenvolvimento de aplicac oes interati-
vasapresentado na Sec ao 3.1, foi utilizado o framework LuaOnTV, como ponto de partida,
no qual foram realizadas melhorias a serem apresentadas neste captulo.
O LuaOnTV[J unior e Gondim 2009] e um framework para facilitar o desenvolvimento
de aplicac oes procedurais para o Sistema Brasileiro de TV Digital, utilizando a linguagem
Lua, por meio de scripts NCLua (scripts Lua embutidos em documentos NCL). O mesmo foi
resultado de trabalho de projeto de pesquisa desenvolvido por equipe do Laborat orio de TV
Digital Interativa da Universidade de Braslia, sob orientac ao do professor Paulo Roberto
de Lira Gondim. Ele foi um projeto pioneiro para o SBTVD, desenvolvido inteiramente
em linguagem Lua, sob o paradigma de programac ao orientada a objetos, que disponibiliza
um conjunto de classes e componentes visuais e n ao visuais para o desenvolvimento de
aplicac oes interativas para TVD.
Os componentes do LuaOnTV utilizam os m odulos canvas e event existentes em NCLua.
Tais m odulos estendem as funcionalidades da linguagem Lua para o contexto de TV Digital.
Desta forma, o framework est a totalmente em conformidade com as normas do Ginga-NCL.
O framework tem como principal objetivo facilitar a construc ao de interfaces gr acas para
aplicac oes interativas, disponibilizando componentes para entrada e sada de dados, al em de
automatizar o processo de controle de foco.
Os componentes visuais foram desenvolvidos com base nos componentes existentes em
diferentes linguagens de programac ao e ambientes integrados de desenvolvimento (IDEs)
como NetBeans, Eclipse, Adobe Dreamweaver, Delphi, Visual Studio e outros; al em de
ferramentas especcas para TV Digital como Jame Author e Cardinal Studio.
[J unior e Gondim 2009] compararam uma aplicac ao desenvolvida utilizando a NCL
como linguagem principal e outra utilizando o LuaOnTV, que tem a linguagem Lua como
principal, e constataram que:
uma aplicac ao com c odigos NCL e imagens que simulam os componentes
gr acos do LuaOnTV chegou a quase 1,5MB. A mesma aplicac ao desenvolvida
51
com LuaOnTV chegou a pouco mais de 60 KB.
Eles tamb em comentam que o framework tem como um dos requisitos n ao funcionais a
diminuic ao do tamanho do c odigo das aplicac oes interativas, considerando as capacidades
restritas de mem oria e armazenamento dos conversores de TV Digital. Tal requisito foi
alcancado devido ` a utilizac ao do paradigma de orientac ao a objetos, que permite uma alta
reutilizac ao de c odigo.
4.1 Delimitac ao do Problema
Devido ` a linguagem NCL ser uma linguagem apenas declarativa, funcionando como uma
linguagem de cola para diferentes tipos de mdias (como GIF, JPEG, MPEG, PNG, XHTML,
e outros, n ao restringindo nem prescrevendo nenhum tipo de mdia)[ABNT 2008], ela e uma
linguagem de maior nvel de abstrac ao, n ao decompondo o resultado em uma implementac ao
algortmica[Barbosa e Soares 2008]. No entanto, tal linguagem n ao permite realizac ao de ta-
refas especcas como operac oes aritm eticas, utilizac ao direta de protocolos de comunicac ao
como TCP, HTTP e SOAP, manipulac ao de arquivos, muito menos a denic ao de procedi-
mentos (rotinas/func oes). Desta forma, a realizac ao de tais tarefas s o e possvel por meio de
uma linguagem procedural como a linguagem Lua.
No caso de entrada de dados, apesar do sub-sistema Ginga-NCL do middleware Ginga
especicar um recurso de teclado virtual a ser utilizado por aplicac oes NCL[ABNT 2008], a
implementac ao de refer encia do mesmo[PUC-Rio 2010] ainda n ao inclui tal recurso. Al em
disto, a manipulac ao de dados (armazenamento e obtenc ao) em documentos NCL n ao e t ao
trivial como a inclus ao de mdias como imagens e vdeos.
Em NCL e possvel at e mesmo denir o controle de foco entre campos (por meio dos
atributos moveLeft, moveRight, moveUp, moveDown, da tag descriptor[ABNT 2008]) per-
mitindo que o usu ario navegue de um campo a outro utilizando as setas do controle remoto.
No entanto, a denic ao da navegac ao entre os campos e feita de forma completamente ma-
nual, e a inclus ao ou remoc ao de um novo campo no meio dos campos existentes requer a
redenic ao da ordem de navegac ao entre os mesmos, o que pode ser um trabalho cansativo
e suscetvel a erros.
Os m odulos de NCLua, utilizados pelo LuaOnTV, disponibilizam apenas um conjunto de
func oes b asicas especcas. Existem 5 m odulos, como apresentados a seguir[ABNT 2008]:
canvas: oferece uma API para desenhar primitivas gr acas e manipular imagens;
event: permite que aplicac oes NCLua comuniquem-se com o middleware atrav es de
eventos (eventos NCL e de teclas);
settings: exporta uma tabela com vari aveis denidas pelo autor do documento NCL e
vari aveis de ambiente reservadas em um n o application/x-ginga-settings;
52
persistent: exporta uma tabela com vari aveis persistentes, que est ao disponveis para
manipulac ao apenas por objetos procedurais.
A utilizac ao direta das func oes destes m odulos requer um conhecimento mais profundo
dos mesmos, como temos provado durante a pesquisa e estudos de tais m odulos, para o de-
senvolvimento de aplicac oes. As funcionalidades de captura de teclas (providas pelo m odulo
event) para entrada de dados alfab eticos e num ericos, da mesma forma como em um teclado
de celular (devido o controle remoto s o possuir teclas num ericas) n ao e trivial. O controle de
foco a partir da captura do pressionamento das teclas direcionais do controle tamb em e com-
plicado e requer a inclus ao de muito c odigo. Tais diculdades t em se provado verdade pelos
diversos relatos de usu arios, como no F orum da Comunidade Ginga no Portal do Software
P ublico[PUC-Rio 2010], al em de outros grupos de discuss ao acompanhados.
Com todas as diculdades apresentadas, o LuaOnTV se mostrou ser uma soluc ao ideal
para a reduc ao da quantidade de c odigo para a criac ao de aplicac oes procedurais com inter-
face gr aca para a TVD, permitindo encapsular toda a complexidade envolvida na utilizac ao
direta dos m odulos de NCLua para chegar ao mesmo m.
4.2 LuaOnTV 2.0: Nova vers ao implementada
Da mesma forma que todo projeto de software, foi implementada e liberada uma pri-
meira vers ao do LuaOnTV. Como extens ao do trabalho de mestrado onde foi originado o
mesmo, vericou-se que eram necess arias algumas melhorias e correc oes de alguns bugs
encontrados. Nesta sec ao ser a apresentada a vers ao 2.0 do LuaOnTV, que traz uma s erie de
importantes novos recursos.
A seguir s ao listados os requisitos funcionais e n ao funcionais, inicialmente identicados
e implementados.
Requisito Funcional N ao Funcional
A.6-01) Correc ao de bugs e melhoria de desempenho na entrada de dados e desenho da interface
de usu ario
x
A.6-02) Reduc ao da quantidade de c odigo para incluir e congurar um componente na tela x
A.6-03) Criac ao de exemplos com os novos recursos implementados x
A.6-04) Adaptac ao de interface para dispositivos port ateis x
A.6-05) Adaptac ao de interface para diferentes denic oes de tela x
A.6-06) Temas para os componentes gr acos x
A.6-07) Posicionamento e dimens oes de componentes e fontes em percentual x
A.6-08) Centralizac ao da interface na tela do dispositivo em casos onde a denic ao da tela for
maior do que a da aplicac ao
x
Tabela 4.1: Requisitos funcionais e n ao funcionais implementados na nova vers ao do
LuaOnTV
53
4.2.1 Melhoria de Desempenho
Um dos principais problemas do LuaOnTV em sua vers ao 1.0 estava relacionado ao de-
sempenho. Durante a utilizac ao do mesmo, foi detectada uma lentid ao na resposta aos even-
tos disparados pelo usu ario (como a mudanca de foco e entrada de caracteres pelo controle
remoto). Foi realizada uma investigac ao, estudando-se a arquitetura do framework, onde
observou-se que a causa de tal lentid ao era devida ao redesenho de todos os componentes na
tela, a cada bot ao que o usu ario pressionava no controle remoto, ou a cada mudanca de foco
ocorrida. O m odulo canvas de NCLua, utilizado para desenhar os campos e imagens na tela,
permite trabalhar com camadas, no entanto, as camadas n ao s ao totalmente independentes.
Assim, quando uma camada e composta sobre outra, esta passa a ser parte da segunda ca-
mada, n ao permitindo mais a separac ao entre elas, o que avalia-se que foi o principal motivo
para os autores do framework realizarem o total redesenho da tela a cada evento ocorrido,
causando a lentid ao bastante perceptvel.
O problema acima descrito foi corrigido: assim, a tela s o e totalmente desenhada no
momento em que a aplicac ao e inicializada. A cada evento ocorrido, somente a parte afetada
da tela e redesenhada. Por exemplo, quando um componente n ao est a em foco, sua borda
padr ao e de cor preta. Quando ele recebe foco, a borda e alterada para vermelha. Desta
forma, neste evento, implementou-se a alterac ao apenas na borda dos componentes anterior e
atual (que perdeu o foco e que recebeu o foco, respectivamente). Da mesma forma no evento
de pressionamento de teclas, somente o componente atual tem sua interface redesenhada
para reetir as alterac oes realizadas pelo usu ario por meio do controle remoto.
4.2.2 Temas
A criac ao de interfaces gr acas com o LuaOnTV n ao permitia a denic ao da apar encia
dos componentes de forma centralizada, a n ao ser alterando o c odigo nas classes do fra-
mework. Caso o desenvolvedor desejasse denir caractersticas visuais diferentes das es-
pecicadas pelo framework, uma alternativa seria denir em cada componente inserido, as
caractersticas desejadas (como estilo e tamanho de fonte, cores, dimens oes e posiciona-
mento). Tal abordagem torna bastante trabalhoso o processo de mudar a apar encia atual,
precisando-se denir tais caractersticas para todos os objetos instanciados.
Tendo em vista tal deci encia, foi implementado no framework um recurso de temas.
Este recurso e bastante conhecido em aplicac oes de diferentes plataformas, como e o caso
do recurso denominado look-and-feel da biblioteca de componentes Swing da plataforma
Java[Fowler 2000]. A Swing e uma biblioteca bastante conhecida pelos desenvolvedores
Java. Sua vers ao atual e bastante madura e est avel e seu modelo de componentes e fortemente
denido em uma arquitetura orientada a objetos, seguindos padr oes de projetos consolidados
pela academica e pela ind ustria de software. O recurso de look-and-feel possibilita ao Swing
ser executado em diferentes plataformas de hardware e sistemas operacionais, adaptando a
54
interface dos componentes visuais de acordo com os temas suportados pela plataforma.
O recurso de temas do LuaOnTV seguiu esse exemplo de larga utilizac ao e amplo su-
cesso do Swing. Desta forma, foi implementada uma classe Theme que e a classe base
para implementac ao de qualquer tema. A partir desta classe, foram criadas as classes Mas-
terTheme e DefaultTheme. A MasterTheme dene as caractersticas padr oes para todos os
temas. A DefaultTheme implementa o tema padr ao a ser utilizado pelas aplicac oes caso
nenhum seja denido pelo programador.
A classe ThemeManager e respons avel por carregar um determinado tema para os com-
ponentes da aplicac ao.
A classe do tema (como DefaultTheme) cont em as caractersticas que ser ao herdadas por
todos os componentes utilizando o tema. Para cada componente do LuaOnTV pode-se de-
nir uma classe de tema associada a um tema especco. Tal classe dene as caractersticas
especcas de um componente, e pode sobrescrever as caractersticas para as propriedades
comuns denidas na classe principal do tema. O desenvolvedor pode ainda sobrescrever as
caractersticas do tema atual, denindo novos valores para as propriedades de um compo-
nente no momento de instanci a-lo ou setando propriedades especcas posteriormente, por
meio dos m etodos setters
1
do componente.
O conjunto de classes de temas permitem que sejam criados temas para diferentes
denic oes de tela (como Low Denition, Standard Denition, High Denition e Full High
Denition), permitindo a adaptac ao autom atica da interface da aplicac ao, de acordo com a
resoluc ao da tela do dispositivo onde a mesma vai executar, seja uma TV CRT conectada a
um Set-top Box, uma TV LCD/Plasma/LED HD ou Full HD, um notebook ou at e mesmo um
celular com o middleware Ginga.
Considerando que apenas o sub-sistema Ginga-NCL e obrigat orio para dispositivos
port ateis com TV Digital Interativa (como celulares), e que o Ginga-NCL e Ginga-J devem
estar presentes em todas as implementac oes de Ginga para receptores xos e m oveis, o de-
senvolvimento de aplicac oes com garantia de execuc ao em todos os tipos de dispositivos com
Ginga s o e possvel se desenvolvidas para o Ginga-NCL. Desta forma, o desenvolvimento
de aplicac oes em Ginga-J n ao garante que poder ao ser executadas tamb em em dispositivos
port ateis.
Assim, para que o desenvolvedor n ao tenha que implementar duas aplicac oes (uma em
Ginga-J para receptores xos e m oveis e outra em Ginga-NCL para receptores port ateis), e
preciso implementar a aplicac ao em Ginga-NCL. No entanto, mesmo em Ginga-NCL, utili-
zando as bibliotecas de NCLua citadas anteriormente, pode haver um grande trabalho para
adaptar a interface da aplicac ao para diferentes dispositivos e denic oes de tela. O recurso
de temas implementado no LuaOnTV permite que todos esses detalhes sejam abstrados pela
criac ao de temas diferentes para dispositivos e denic oes de telas diferentes.
1
M etodos respons aveis por alterar o conte udo de um determinado atributo de uma classe
55
Um dos recursos implementados, utilizados pelos temas, que permitem essa inde-
pend encia de denic ao de tela foi o de informar posic oes, dimens oes e tamanho de fonte
de componentes por meio de valores percentuais. O m odulo canvas de NCLua s o permite
o uso de valores absolutos em suas func oes. Tais funcionalidades foram estendidas pelo
LuaOnTV, tendo por base os recursos das Folhas de Estilo em Cascata (Cascade Style She-
ets, CSS)[W3C 2009], amplamente utilizadas em p aginas HTML.
Tal recurso permite a adaptac ao autom atica da fonte e das dimens oes do componente, de
acordo com o tema denido, adicionando recursos de acessibilidade nas aplicac oes intera-
tivas, pois o tamanho da fonte e dos componentes pode ser alterado dinamicamente. Desta
forma, o desenvolvedor pode incluir os conhecidos bot oes A+e A-na aplicac ao, para
dinamicamente aumentar ou diminuir o tamanho da fonte da aplicac ao.
Alguns outros recursos implementados no LuaOnTV foram:
posicionamento autom atico de campos na tela: caso o desenvolvedor n ao informe
posic oes (left e top) para um componente, ele ser a automaticamente posicionado na
tela, com base nas coordenadas do ultimo componente inserido, permitindo um ajuste
autom atico da interface em telas de denic oes diferentes;
centralizac ao de layout autom atico na tela de diferentes dispositivos: permite cen-
tralizar a interface da aplicac ao na tela do dispositivo, em casos de a aplicac ao estar
executando em telas de grandes denic oes, o que pode fazer com que sobre espaco nos
quatro lados da tela;
simplicac ao do conjunto de classes e componentes: criac ao de um unico componente
para permitir a entrada de texto, de n umeros e de senhas. Propriedades foram adicio-
nadas para denir o comportamento de entrada de dados no componente;
simplicac ao do modelo de construc ao de aplicac oes: foi reduzida a quantidade de
c odigo necess aria para incluir um componente na tela, implementando, por exemplo,
o controle autom atico de foco. Assim, a cada campo includo, ele automaticamente re-
cebe uma numerac ao que dene sua ordem na tela. Desta forma, o framework conhece
automaticamente a ordem dos componentes.
A Figura 4.1 apresenta o novo diagrama de classes dos componentes do LuaOnTV.
56
Figura 4.1: Novo diagrama de classes do LuaOnTV
57
Neste diagrama, a classe EventManager tem um papel fundamental no framework, pois
ela e respons avel pelo tratamento dos eventos ocorridos na aplicac ao, principalmente os
eventos de pressionamento de teclas, controlando a entrada de dados na tela e a navegac ao
entre os campos por meio das teclas direcionais do controle remoto. Desta forma, a Figura
4.2 apresenta um gr aco de m aquinas estados desta classe.
Figura 4.2: Gr aco de M aquinas de Estados da classe EventManager
Um dos principais novos recursos implementados no LuaOnTV foi o suporte a temas. A
Figura 4.3 apresenta as classes relacionadas a tal recurso.
Figura 4.3: Classes relacionadas ao novo recurso de temas do LuaOnTV
58
Como mencionado anteriormente, o LuaOnTV utiliza os m odulos canvas e event do
Ginga-NCL. Assim, a Figura 4.4 apresenta um diagrama de componentes, mostrando como
os elementos do LuaOnTV e do Ginga-NCL se relacionam. O LuaOnTV possui dois paco-
tes principais: Components, contendo as classes que implementam os componentes visuais
e n ao visuais; e Themes, contendo as classes que implementam os temas. O LuaOnTV cria
uma camada de abstrac ao para os m odulos canvas e event do Ginga-NCL, provendo funcio-
nalidades de mais alto nvel.
Figura 4.4: Diagrama de Componentes do LuaOnTV
59
Captulo 5
Framework de comunicac ao de dados
A arquitetura apresentada no Captulo 3 utiliza protocolos de comunicac ao HTTP e
SOAP. Tais protocolos foram implementados em um framework de comunicac ao a ser apre-
sentado neste captulo.
5.1 Integrac ao entre Web e TV
Um dos grandes atrativos da TV Digital (TVD) e com certeza a interativi-
dade. Existem diversas categorias de aplicac oes interativas como jogos, informac oes
(notcias, hor oscopo, previs ao do tempo, etc), educac ao (T-Learning), governo eletr onico
(T-Government), com ercio eletr onico (T-Commerce), sa ude (T-Health), banc arias (T-
Banking) e outras, como apresentado em [Fern andez e Goldenberg 2008], [Teixeira 2006]
e [Barbosa, Kutiishi e Lima 2010].
O nvel de interatividade das aplicac oes vai desde a chamada interatividade local
(onde os usu arios/telespectadores podem acessar apenas os dados enviados pela emissora,
por radiodifus ao) at e a interatividade plena (onde os usu arios/telespectadores disp oem de
um canal de retorno, permitindo enviar e receber dados em uma rede como a Internet)
[Soares e Barbosa 2009].
Tais aplicac oes que permitem interatividade plena precisam utilizar protocolos de
comunicac ao padr oes e consolidados na Internet (como TCP, HTTP e SOAP) para garan-
tir a interoperabilidade com outros sistemas.
Utilizando os protocolos citados, e possvel garantir a converg encia entre Web e TV. Com
isto, as aplicac oes de TVDi podem ser enriquecidas com conte udo proveniente da Internet,
como e o caso da aplicac ao que busca conte udo na Wikip edia, baseada nas tags do programa
em exibic ao, obtidos a partir do Guia Eletr onico de Programac ao (cujas informac oes s ao
enviadas pela emissora), como apresentado em [Ghisi, Lopes e Siqueira 2010].
A norma do sub-sistema Ginga-NCL do middleware Ginga dene apenas a obrigatorie-
60
dade do protocolo TCP. Quaisquer protocolos acima da camada de transporte precisam ser
implementados pelo desenvolvedor de aplicac oes.
Tendo em vista o cen ario supracitado, s ao apresentados neste trabalho os projetos NCLua
HTTP e NCLua SOAP: implementac oes dos protocolos HTTP e SOAP, respectivamente,
para o sub-sistema Ginga-NCL, utilizando linguagem Lua, que permitem a converg encia
entre aplicac oes de TVDi e a Web.
A escolha de implementac ao de HTTP e SOAP partiu da inexist encia de vers oes livres e
de c odigo aberto de tais protocolos para o Ginga-NCL. At e onde sabe-se, o NCLua HTTP e
NCLua SOAP s ao as primeiras implementac oes livremente disponibilizadas.
5.2 Delimitac ao do Problema
Apesar de Lua ser uma linguagem extensvel [Ierusalimschy, Figueiredo e Celes 2007],
principalmente pela capacidade de utilizar m odulos construdos em linguagem C, e de exis-
tirem v arios destes m odulos para as mais diversas nalidades, tais m odulos bin arios n ao
podem ser utilizados em aplicac oes interativas de TV Digital enviadas via broadcast, devido
a quest oes de seguranca, uma vez que um m odulo escrito em linguagem C pode ter acesso a
qualquer funcionalidade do sistema operacional (embarcado juntamente com o middleware
no receptor de TV Digital).
Em [Braga e Restani 2010] s ao citadas algumas ameacas de seguranca em sistemas
de TVDi, como transac ao fraudulenta (perda/roubo de dados), pirataria de conte udo,
falsicac ao, violac ao ou corrupc ao das aplicac oes e uso ilegtimo de servicos do provedor.
Tais ameacas podem ser potencializadas com o uso de m odulos bin arios. Al em do mais,
a compilac ao de m odulos em C gera c odigo nativo dependente de plataforma, o que n ao
garante que a aplicac ao executar a em qualquer receptor [Costa 2009]. Somente aplicac oes
residentes podem ser desenvolvidas em linguagens compiladas como C.
Com isto, para haver, em aplicac oes NCLua de TVDi, algumas das funcionalidades dos
m odulos bin arios citados, e preciso implementar m odulos inteiramente em linguagem Lua,
cujo ciclo de vida e controlado pelo middleware Ginga[ABNT 2008].
5.3 Tecnologias Envolvidas e Trabalhos Relacionados
Nesta sec ao s ao apresentadas as tecnologias envolvidas no desenvolvimento da soluc ao
apresentada e os trabalhos relacionados.
61
5.3.1 Tecnologias de Web Services
SOAP e um protocolo padr ao da World Wide Web Consortium (W3C) que permite a
aplicac oes oferecerem seus servicos na Internet, em uma arquitetura distribuda no modelo
cliente/servidor. O protocolo permite troca de mensagens e chamadas de procedimentos
remotos. Tais servicos podem ser providos e consumidos por aplicac oes desenvolvidas
em diferentes linguagens e plataformas. Isto permite a interoperabilidade entre diferentes
aplicac oes, por meio da troca de documentos XML, usando algum protocolo de transporte
como o HTTP [W3C 2007] [Curbera et al. 2002] [Newcomer 2002].
Um dos grandes benefcios do protocolo SOAP para a integrac ao de aplicac oes e a sua
linguagem para descric ao dos servicos disponibilizados, a Web Service Description Lan-
guage (WSDL). De forma padronizada, manual ou automatizadamente, uma aplicac ao cli-
ente pode conhecer os servicos disponibilizados por um Web Service lendo o documento
WSDL do servico (tamb em em formato XML)[W3C 2007].
Os Web Services permitem a construc ao de aplicac oes distribudas pela Internet, garan-
tindo a centralizac ao de regras de neg ocios em servidores de aplicac oes, encarregados de
toda a carga de processamento de tais regras. Considerando-se isto, Web Services s ao ideais
para aplicac oes clientes executando em sistemas com restritos recursos de hardware, como
celulares e Set-top Boxes, estes ultimos sendo o foco do presente trabalho. Al em de desone-
rar os clientes da carga de processamento, alterac oes nas regras de neg ocio n ao requerem a
atualizac ao das aplicac oes clientes.
5.3.2 Lua e os scripts NCLua
Lua e a linguagem imperativa utilizada pelo sub-sistema Ginga-NCL para o desenvol-
vimento de aplicac oes procedurais. Ela tem como grandes vantagens sua simplicidade,
eci encia e portabilidade. Tais caractersticas s ao extremamente importantes em uma lin-
guagem a ser utilizada em dispositivos com recursos de hardware restritos, como os conver-
sores de TV Digital (Set-top Boxes). Al em de tudo, Lua e livre de royalties, o que permite
que a mesma seja embarcada em Set-top Boxes sem onerar o custo dos equipamentos. Este e
um requisito muito importante, considerando as caractersticas s ocio-econ omicas do Brasil,
a intenc ao do governo de utilizac ao da TV como meio para inclus ao digital e sua presenca
na grande maioria dos lares brasileiros.
Como a linguagem NCL e apenas declarativa, a inclus ao de caractersticas imperativas a
uma aplicac ao de TVDi para o Ginga-NCL e possibilitada por meio dos chamados NCLua,
scripts Lua funcionando como n os de mdia dentro de um documento NCL [ABNT 2008]
[Soares, Rodrigues e Moreno 2007].
Tais scripts aumentam o poder das aplicac oes de TVDi, possibilitando a construc ao de
aplicac oes sosticadas, seguindo paradigmas como Programac ao Estruturada e Programac ao
62
Orientada a Objetos, com denic ao de regras de neg ocio na aplicac ao, interoperabilidade
com sistemas na Internet por meio de protocolos como HTTP e SOAP, entre outros recursos.
O que diferencia os scripts NCLua de scripts Lua convencionais e a possibilidade
de comunicac ao bidirecional entre este e o documento NCL. Tal comunicac ao acon-
tece por meio de eventos, como denido na norma do Ginga-NCL em [ABNT 2008].
Segundo [SantAnna, Cerqueira e Soares 2008] essa integrac ao deve seguir crit erios que
n ao afetem os princpios da linguagem declarativa, mantendo uma separac ao bem de-
nida entre os dois ambientes. Para isto, nenhuma alterac ao nas linguagens NCL ou
Lua foi necess aria, o que garante a evoluc ao independente das linguagens, como ressalta
[SantAnna, Cerqueira e Soares 2008].
A integrac ao entre as linguagens NCL e Lua foi feita para ser minimamente intrusiva,
garantindo uma separac ao entre a forma declarativa e a procedural de desenvolver uma
aplicac ao para o Ginga-NCL. Assim, o c odigo NCLua deve ser escrito obrigatoriamente
em um arquivo separado do NCL. Isto permite uma clara divis ao de tarefas entre pros-
sionais da area de design e da area de programac ao [SantAnna, Cerqueira e Soares 2008].
A integrac ao entre outras linguagens como HTML e JavaScript e bastante intrusiva, onde,
muitas vezes, c odigo JavaScript e intercalado com c odigo HTML.
O tratamento de eventos e as particularidades associadas a aplicac oes de TVDi, desenvol-
vidas em linguagem Lua, s ao implementadas por m odulos adicionais ` a Linguagem, denidos
na norma do Ginga-NCL [ABNT 2008]. Isto permite que a linguagem se mantenha inalte-
rada para o contexto de TV Digital. Os m odulos disponveis em NCLua, utilizados neste
trabalho s ao: event, que permite a comunicac ao bidirecional entre um NCL e um NCLua; e
canvas, que disponibiliza uma API para desenhar imagens e primitivas gr acas.
5.3.3 Protocolo TCP no Ginga-NCL
A norma do Ginga-NCL [ABNT 2008] dene a disponibilidade do protocolo TCP para
ser utilizado pelas aplicac oes interativas. Como os objetos NCLua t em a caracterstica de
poderem ser orientados a eventos, o m odulo event permite a captura e tratamento de eventos,
possibilitando a comunicac ao assncrona entre o formatador NCL e um objeto NCLua.
A implementac ao do protocolo TCP deve ser disponibilizada por meio do m odulo event.
A norma especica uma classe de eventos denominada tcp. Assim, por meio das func oes
do m odulo event, um objeto NCLua pode enviar requisic oes e receber respostas usando o
protocolo TCP.
Devido ` a caracterstica assncrona do m odulo event, o tratamento de requisic oes TCP
em NCLua n ao e trivial. Para facilitar o uso de tal protocolo, pode-se recorrer ao recurso
de co-rotinas da linguagem Lua. Segundo [Ierusalimschy 2006], uma co-rotina e similar a
um thread (no sentido de multithreading). No entanto, co-rotinas s ao colaborativas, sendo
executada apenas uma por vez.
63
A documentac ao de NCLua disponvel em [SantAnna 2010], apresenta um m odulo que
utiliza co-rotinas para facilitar o tratamento das requisic oes assncronas da classe de eventos
tcp. No entanto, mesmo tal m odulo ainda n ao permite encapsular todos os detalhes do envio
da requisic ao em apenas uma func ao, para simplicar o uso para os desenvolvedores de
aplicac oes interativas.
A Figura 5.1 apresenta um gr aco de m aquinas de estados da realizac ao de uma co-
nex ao TCP no Ginga-NCL, utilizando o m odulo tcp.lua. Em um processo convencional, a
aplicac ao estabelece uma conex ao a um servidor. Ap os estabelecida a conex ao ela envia uma
requisic ao e ca aguardando o retorno. A func ao tcp.receive e executada at e que n ao haja
mais dados a serem recebidos, realizando a desconex ao.
Figura 5.1: Diagrama de M aquinas de Estados do M odulo tcp.lua
A Figura 5.2 apresenta um gr aco de m aquinas de estados do mesmo m odulo, por em, do
ponto de vista das co-rotinas em execuc ao (que s ao semelhantes a threads, como j a discutido
anteriormente). O processo de uso do m odulo e iniciado internamente com a criac ao de uma
corotina (que e criada suspensa, n ao automaticamente iniciando sua execuc ao). A func ao co-
routine.resume inicia a execuc ao da co-rotina. Quando e solicitada uma tentativa de conex ao,
a co-rotina e suspensa, cando aguardando at e que a conex ao seja estabelecida, ocorrendo
tudo de forma assncrona. Neste momento, a co-rotina e novamente resumida (continuando
a execuc ao), permitindo que seja enviada uma requisic ao ao servidor (tcp.send). Tal func ao
retorna imediatamente. Para a obtenc ao da resposta da requisic ao (que tamb em ser a feita de
forma assncrona), e preciso usar a func ao tcp.receive, que faz com que a co-rotina seja sus-
pensa novamente, at e que algum dado da resposta seja obtido. A func ao tcp.receive pode ser
chamada iterativamente at e que n ao haja mais nenhum dado a ser retornado para a aplicac ao.
Todo este processo apresentado nos gr acos de m aquinas de estado, mesmo utilizando
as facilidades providas pelo m odulo tcp.lua, n ao s ao encapsulados para facilitar o uso. O
m odulo citado apenas facilita o gerenciamento das chamadas assncronas. A implementac ao
do NCLua HTTP e NCLua SOAP encapsulam todas essas chamadas de func oes, tornando o
processo bem mais simples para o desenvolvedor, disponibilizando uma simples func ao para
realizac ao de uma requisic ao.
E importante lembrar que tal abordagem e util em cen arios de aplicac oes stateless, que
n ao mant em estado entre uma requisic ao e outra, como o caso do HTTP/1.0 e das chamadas
SOAP. Aplicac oes que precisem manter a conex ao aberta, como mensageiros instant aneos,
precisam utilizar diretamente as func oes do m odulo tcp.lua.
64
Figura 5.2: Diagrama de M aquinas de Estados do M odulo tcp.lua (co-rotinas em execuc ao)
5.3.4 Implementac oes de SOAP
Existem diversos toolkits para provimento e consumo de Web Services, disponveis em
diferentes linguagens e plataformas. Nas sub-sec oes seguintes s ao apresentados alguns des-
tes.
5.3.4.1 LuaSOAP
Para acesso a Web Services SOAP a partir de aplicac oes Lua, pode-se utilizar o m odulo
LuaSOAP [Ierusalimschy, Carregal e Guisasola 2004].
O protocolo SOAP envolve a troca de mensagens em formato XML, permitindo
a interoperabilidade entre sistemas desenvolvidos em diferentes linguagens. No en-
tanto, para fazer o parse de arquivos XML, o LuaSOAP depende da biblioteca Expat
[Jr e Waclawek 2007][Cooper 1999], que e um parser XML desenvolvido em linguagem C,
cujos problemas de uso em aplicac oes de TVDi foram apresentados na Sec ao 5.2. O projeto
tamb em depende da biblioteca LuaSocket, que tamb em usa m odulos em C.
O LuaSOAP n ao permite a gerac ao autom atica de stubs para realizar a chamada aos
m etodos remotos do Web Service. Desta forma, o desenvolvedor precisa ler o documento
WSDL e obter as informac oes sobre o m etodo que deseja invocar. A ultima atualizac ao do
projeto foi em 2004, o que mostra que o mesmo n ao est a acompanhando as novas vers oes de
Lua, como a 5.1 utilizada na implementac ao de refer encia do Ginga.
Uma das vantagens do projeto e que as chamadas aos m etodos remotos no Web Service
s ao sncronas, o que facilita bastante o uso.
5.3.4.2 gSOAP
O gSOAP e classicado como um Software Development Kit (SDK) para permitir que
aplicac oes legadas, sistemas embarcados e de tempo real, desenvolvidos em linguagens C,
C++ e Fortran, possam consumir Web Services [Engelen e Gallivan 2005]. O projeto possui
um utilit ario capaz de gerar stubs em C/C++, a partir do documento WSDL do servico.
Em tal stub s ao includos m etodos proxies para realizar chamadas aos m etodos remotos do
servico, tornando-as transparentes para a aplicac ao cliente.
65
As chamadas realizadas com gSOAP tamb em s ao sncronas, o que facilita muito o de-
senvolvimento das aplicac oes clientes, pois o envio da requisic ao e tratamento da resposta
pode ser todo feito em uma unica rotina.
Pelo fato do projeto ser desenvolvido em C, o mesmo s o poderia ser utilizado em
aplicac oes de TVD residentes no conversor digital, como j a comentado na Sec ao 5.2. A
utilizac ao de linguagens compiladas como C/C++ permite que o (un)marshalling seja feito
em tempo de compilac ao, o que garante que a aplicac ao ter a maior velocidade na execuc ao.
No entanto, a necessidade de tal processo de compilac ao elimina a grande vantagem do di-
namismo existente em linguagens interpretadas como Lua.
5.3.4.3 Apache Axis
Em [Davis e Parashar 2005] s ao apresentados alguns outros toolkits para provimento e
consumo de Web Services. Um dos projetos citados e o Apache Axis, uma implementac ao
de SOAP para Java e C, que tem, como uma das vantagens, o uso do parser XML SAX, o
qual e completo e bastante eciente. Ele tamb em possui a vantagem de gerar stubs Java ou
C, a partir do documento WSDL.
Mesmo o Ginga permitindo o uso de Java, o Apache Axis pode n ao ser uma soluc ao
ideal para aplicac oes de TVD, uma vez que inclui o SAX como parser XML. Considerando
a capacidade de hardware restrita dos conversores de TV Digital, tal parser pode n ao ser
ideal em tais equipamentos, al em de poder n ao estar em conformidade com as normas do
Sistema Brasileiro de TV Digital (SBTVD). Parsers mais simples como o NanoXML
1
, que
demandam menos capacidade de processamento, podem ser mais adequados neste cen ario.
Por m, o Apache Axis n ao atende a um dos requisitos elicitados: ser implementado em Lua
para uso direto por aplicac oes NCLua.
5.4 Proposta de Novas Implementac oes de HTTP e SOAP
O Ginga-NCL prov e protocolos de rede at e o TCP, assim, qualquer protocolo acima da
camada de transporte do modelo OSI precisa ser implementado. Como o envio de envelopes
SOAP e normalmente feito por HTTP, tal protocolo precisou ser implementado como um
m odulo NCLua, ao qual denominou-se NCLua HTTP, que ser a utilizado pelo NCLua SOAP.
5.4.1 Decis oes de Projeto
Para o desenvolvimento do projeto, optou-se por seguir o padr ao de m odulos, ampla-
mente utilizado na atual vers ao da linguagem Lua. Um m odulo encapsula func oes com
objetivos correlatos e tal padr ao e bastante conhecido dos programadores Lua.
1
http://nanoxml.sourceforge.net
66
Tal modelo segue o paradigma de programac ao estruturada, assim, um m odulo consiste
de um conjunto de func oes que s ao chamadas pelo desenvolvedor que for utiliz a-lo.
Na gerac ao das requisic oes SOAP, optou-se por fazer o (un)marshalling de XML para
tabelas Lua por estas serem as estruturas de dados padr oes disponibilizadas pela linguagem
e por serem estruturas bastante exveis e f aceis de manipular, devendo ser de conhecimento
de qualquer programador Lua.
Como o conte udo das requisic oes HTTP e SOAP e apenas texto, formatado segundo
o padr ao de cada protocolo, a gerac ao e formatac ao deste conte udo foi bastante simples
e direta. Devido a strings em Lua serem imut aveis[Ierusalimschy 2006], para economizar
mem oria na concatenac ao das strings que comp oe cada requisic ao, as tabelas de Lua foram
utilizadas como um buffer de strings para otimizar o uso de mem oria RAM.
Na obtenc ao dos resultados, procurou-se facilitar ao m aximo tal tarefa para o desenvol-
vedor, permitindo que ele tenha acesso direto aos dados retornados, sem precisar conhecer
o caminho dentro do XML de retorno onde a resposta est a armazenada, assim como fazem
outros toolkits SOAP como a API JAX-WS.
Quanto ao parser XML escolhido, n ao haviam muitas opc oes implementadas intei-
ramente em Lua. Todas as implementac oes testadas foram encontradas em http://
lua-users.org e em [Ierusalimschy 2006]. Optou-se pelo uso do LuaXML
2
, pois foi
a implementac ao que fazia o unmarshalling de XML para tabelas Lua com a estrutura mais
simples e f acil de manipular. Al em do mais, as outras implementac oes encontradas n ao fun-
cionaram adequadamente para XMLs mais complexos retornados por alguns Web Services.
5.4.2 NCLua HTTP
O NCLua HTTP
3
implementa alguns dos principais recursos do protocolo HTTP/1.0. Ele
e um m odulo escrito inteiramente em linguagem Lua para ser utilizado em scripts NCLua.
O mesmo utiliza o protocolo TCP da forma como especicado na norma do Ginga-NCL em
[ABNT 2008], por meio da classe de eventos tcp de NCLua. Pela simplicidade do protocolo
HTTP, o m odulo possui apenas algumas func oes que permitem a gerac ao de requisic oes e
tratamento de respostas. Atualmente existem os seguintes recursos implementados:
suporte ` a autenticac ao b asica, uso de portas especcas e download de arquivos;
suporte ` a requisic oes GET e POST;
passagem de par ametros em requisic oes POST;
suporte ` a passagem de cabecalhos HTTP e denic ao de User-Agent;
2
http://lua-users.org/wiki/LuaXml
3
http://ncluahttp.manoelcampos.com e http://labtvdi.unb.br
67
suporte ` a separac ao autom atica dos dados do cabecalho e do corpo da resposta de uma
requisic ao.
5.4.3 NCLua SOAP
O NCLua SOAP
4
implementa as principais funcionalidades do protocolo SOAP 1.1 e
1.2. Ele tamb em e um m odulo inteiramente escrito em Lua, que faz o parse de arquivos
XML, realizando o marshalling e unmarshalling de/para tabelas Lua, permitindo que o de-
senvolvedor Lua trabalhe com a estrutura de dados principal da linguagem: o tipo table.
O m odulo utiliza o NCLua HTTP para transportar as mensagens SOAP. Assim, todos
os detalhes do protocolo HTTP s ao encapsulados pelo respectivo m odulo. Com isto, a
implementac ao do SOAP ca bastante simplicada, tornando o c odigo f acil de ser man-
tido. O NCLua SOAP encarrega-se apenas de gerar o XML da requisic ao SOAP, utilizando
o NCLua HTTP para enviar tal XML no corpo da mensagem. O parse e unmarshalling do
XML para uma tabela Lua e todo encapsulado pelo m odulo LuaXML
5
.
Um importante recurso, n ao disponvel em implementac oes como o LuaSOAP (ci-
tada na Sec ao 5.3), e que facilita bastante a utilizac ao do m odulo, e a simplicac ao do
XML retornando como resposta, que e convertido (unmarshalling) automaticamente para
uma tabela Lua. Para demonstrar este recurso, utilizar-se- a o Web Service de consulta de
endereco a partir de um CEP, disponvel em http://www.bronzebusiness.com.
br/webservices/wscep.asmx. Tal WS possui um m etodo chamado cep, que re-
cebe um determinado CEP e retorna o endereco referente ao mesmo. O XML do retorno do
m etodo cep, convertido para uma tabela Lua, e semelhante ao mostrado na Listagem 5.1.
A estrutura da tabela reete o c odigo XML retornado. Como pode ser visto, o elemento
da tabela que cont em de fato os dados do endereco retornado (tbCEP) est a envolvido em
v arias outras tabelas que n ao cont em dado algum, sendo estruturas completamente desne-
cess arias para a aplicac ao NCLua. Com isto, para o desenvolvedor poder acessar, por exem-
plo, a cidade do CEP indicado, precisar a conhecer toda a estrutura retornada, utilizando uma
instruc ao como result.cepResult.diffgr.NewDataSet.tbCEP.cidade.
Para esconder estes detalhes do desenvolvedor, o NCLua SOAP simplica qualquer re-
sultado que contenha estruturas desnecess arias, como o mostrado na Listagem 5.1.
Listagem 5.1: Exemplo de tabela Lua gerada a partir do XML de uma resposta SOAP
1 { c e pRe s ul t = { d i f f g r = { NewDat aSet = { tbCEP = {
2 nome= Cl n 407 , b a i r r o =Asa Nor t e , UF=DF , c i da de = Br a s i l i a
3 } } } } }
Desta forma, para o exemplo citado, a tabela Lua (gerada a partir do XML de retorno
da requisic ao) car a como apresentado na Listagem 5.2, o que simplica o acesso aos ele-
4
http://ncluasoap.manoelcampos.com e http://labtvdi.unb.br
5
Parser XML escrito inteiramente em Lua, adaptado para funcionar com Lua 5
68
mentos da estrutura retornada, permitindo, por exemplo, que o campo cidade seja acessado
utilizando-se apenas a instruc ao result.cidade.
Listagem 5.2: Exemplo de simplicac ao de retorno de resposta SOAP pelo NCLua SOAP
1 { nome= Cl n 407 , b a i r r o =Asa Nor t e , UF=DF , c i da de = Br a s i l i a }
O m odulo ainda conta com um script (wsdlparser.lua), em fase inicial de implementac ao,
que realiza o parse de um documento WSDL e obt em algumas das informac oes que precisa-
se passar ao NCLua SOAP para que ele realize a requisic ao (como o namespace do servico,
o nome do m etodo desejado e a lista de par ametros de entrada). Atualmente o script apenas
l e o WSDL e exibe algumas das informac oes citadas, cabendo ao desenvolvedor copi a-las e
pass a-las ao m etodo call do NCLua SOAP para realizar a chamada a um determinado m etodo
remoto. No entanto, a extrac ao de tais informac oes j a ajuda de alguma forma, principalmente
os usu arios menos experientes na tecnologia de Web Services e no NCLua SOAP.
Para resumir, as caractersticas principais do NCLua SOAP s ao:
suporte a SOAP 1.1 e 1.2;
suporte a par ametros de entrada e sada do tipo struct e array (sendo feito marshalling
e unmarshalling de/para tabelas Lua automaticamente);
facilidade para manipulac ao de chamadas assncronas, caracterstica do protocolo TCP
disponvel no Ginga-NCL;
simplicidade na obtenc ao do retorno de uma requisic ao a um m etodo remoto;
suporte a SOAP Fault para captura de erros SOAP;
suporte a SOAP Header[W3C 2007] possibilitando a passagem de par ametros es-
peccos da aplicac ao (como informac oes sobre autenticac ao, pagamento, etc);
realizac ao de testes com Web Services desenvolvidos em diferentes linguagens.
A Figura 5.3 apresenta um diagrama de componentes dos m odulos implementados. O
m odulo event faz parte do Ginga-NCL e e respons avel por tratar eventos, como requisic oes
e obtenc ao de respostas por meio do protocolo TCP. Ele e a base para toda a implementac ao.
O m odulo tcp.lua facilita o gerenciamento das requisic oes TCP assncronas, geradas por
meio do m odulo event. O m odulo ncluahttp.lua implementa o protocolo HTTP, utilizando o
TCP como camada de transporte. O m odulo ncluasoap.lua implementa o protocolo SOAP,
utilizando o ncluahttp.lua para enviar os envelopes SOAP por HTTP. Uma aplicac ao cliente,
que queira utilizar o protocolo HTTP (NCLua HTTP Client App), pode fazer uso direto
das func oes do m odulo ncluahttp.lua, abstraindo todos os outros m odulos. Uma aplicac ao
cliente, que queira consumir Web Services SOAP (NCLua Web Service Client App), pode
fazer uso direto das func oes do m odulo ncluasoap.lua, tamb em abstraindo todos os outros
m odulos.
69
Figura 5.3: Diagrama de Componentes do NCLua SOAP e NCLua HTTP
5.5 Exemplos de Uso e Testes de Interoperabilidade
Nesta sec ao s ao apresentados os exemplos de utilizac ao e aplicac oes desenvolvidas uti-
lizando os m odulos NCLua HTTP e NCLua SOAP, bem como testes de interoperabilidade
realizados.
5.5.1 Exemplos de uso do NCLua HTTP
A utilizac ao b asica do m odulo NCLua HTTP e por meio de uma chamada GET a uma
determinada URI, utilizando o m etodo request do m odulo, como exemplicado no script
NCLua da Listagem 5.3. Tal exemplo envia uma requisic ao HTTP GET para a p agina em
http://manoelcampos.com/votacao/votacao2.php, enviando um par ametro
votocomvalor igual a sim, obtendo o resultado (umc odigo HTML neste caso) e exibindo
no terminal. N ao existe interface gr aca neste exemplo, desta forma, o script cont em apenas
detalhes da requisic ao HTTP, mas e inteiramente funcional.
Na Listagem 5.3, a linha 1 adiciona o m odulo NCLua HTTP. A linha 8 chama a func ao
http.request que envia a requisic ao HTTP. Devido ` a particularidade assncrona do protocolo
TCP no Ginga-NCL (que e utilizado para transportar as mensagens HTTP), como explicado
na Sec ao 5.3.3, para facilitar o envio de requisic oes e recebimento de respostas, o m odulo
NCLua HTTP utiliza co-rotinas de Lua. Por este motivo, a obtenc ao do retorno deve ser feita
dentro de uma func ao, como a denida na linha 6, contendo os par ametros header e body
(comentados na denic ao da mesma). Tal func ao deve ser passada como par ametro ` a func ao
http.request, para que seja chamada por esta quando a resposta for obtida.
Listagem 5.3: Exemplo de envio de requisic ao GET com NCLua HTTP
1 r e q u i r e h t t p
2 Funcao de c a l l b a c k e x e c ut ada de f orma as s i nc r ona pe l o modulo ,
3 quando a r e s p o s t a da r e q u i s i c a o eh obt i da .
4 @param header Headers HTTP e nv i ados na r e s p o s t a
5 @param body Corpo da mensagem HTTP
6 f u n c t i o n get Res pons e ( header , body ) p r i n t ( Res pos t a o b t i d a \n , body ) end
7
8 h t t p . r e q u e s t ( h t t p : / / manoel campos . com/ vot o . php ? vot o=si m , get Res pons e )
O envio de requisic oes POST e bastante semelhante ao exemplo apresentado anterior-
mente. Neste caso, os par ametros devem ser passados ` a func ao http.request por meio de
70
uma tabela Lua. A formatac ao destes valores, como exigido pelo protocolo HTTP, e feita
automaticamente pelo NCLua HTTP.
Algumas aplicac oes foram desenvolvidas como prova de conceito do uso do m odulo
NCLua HTTP, as quais s ao apresentadas a seguir:
Enquete TVD: enquete com registro de voto e apurac ao a partir de servidor Web;
NCLua RSS Reader: leitor de notcias RSS de um provedor de conte udo na Web;
NCLua Tweet: envio e recebimento de mensagens pelo micro blog Twitter.
5.5.2 Exemplos de uso do NCLua SOAP
A seguir s ao apresentados exemplos de uso do NCLua SOAP para consumo de alguns
Web Services disponveis na Internet.
A Listagem 5.4 apresenta um exemplo de aplicac ao para exibir a previs ao do tempo
de uma cidade. A mesma n ao possui interface gr aca, mostrando o resultado no termi-
nal, para simplicar o c odigo. A linha 10 realiza a chamada ao m etodo remoto. Os dados
para realizac ao da requisic ao (incluindo o endereco do servico, nome do m etodo remoto e
par ametros de entrada) devem ser informados em uma tabela Lua, como mostrado entre as
linhas 4 a 8. A obtenc ao do retorno do m etodo remoto n ao e direta, devido ` a caracterstica
assncrona do protocolo TCP no Ginga-NCL, como j a explanado nas Sec oes 5.3.3 e 5.4.2.
Desta forma, e necess aria a denic ao de uma func ao que deve receber apenas um par ametro
(normalmente nomeado de result), como a func ao getResponse exibida na linha 2. Tal func ao
deve ser passada como par ametro ao m etodo call do m odulo ncluasoap, como mostrado na
linha 10. O envio da requisic ao ser a executado dentro de uma co-rotina Lua, criada pelo
NCLua SOAP. A func ao getResponse ser a executada automaticamente quando o retorno for
obtido. Desta forma, todo o controle das chamadas assncronas e feito pelo NCLua SOAP,
como j a amplamente discutido na Sec ao 5.4.2.
Como o servico consumido neste exemplo retorna apenas uma string com a previs ao
do tempo (chuvoso, nublado, ensolarado, etc), para exibir tal resultado basta imprimir o
par ametro result da func ao getResponse, como apresentado na linha 6.
Listagem 5.4: Exemplo de consumo de Web Service de previs ao do tempo
1 r e q u i r e nc l ua s oa p
2 f u n c t i o n get Res pons e ( r e s u l t ) p r i n t ( Pr e v i s a o do Tempo : , r e s u l t ) end
3
4 l o c a l msg = {
5 a ddr e s s = h t t p : / / www. d e e p t r a i n i n g . com/ we bs e r vi c e s / weat her . asmx ,
6 namespace = h t t p : / / l i t wi n c o n s u l t i n g . com/ we bs e r vi c e s / ,
7 oper at i onName = Get Weat her , par ams = { Ci t y = New York }
8 }
71
9
10 nc l ua s oa p . c a l l ( msg , get Res pons e )
O exemplo apresentado na Listagem 5.5 consume um servico para obtenc ao de um
endereco a partir do CEP. Observe que o que muda entre as linhas 6 e 10, em relac ao ao
exemplo anterior, s ao apenas os valores da tabela msg, que cont em os dados para gerac ao
da requisic ao SOAP. Na func ao getResponse, entre as linhas 2 e 4, note que agora, o resul-
tado retornado e um tipo composto, que e acessado como uma tabela Lua. Tal tabela conter a
campos com os valores armazenados no XML enviado pelo Web Service.
Listagem 5.5: Exemplo de consumo de WS de consulta de endereco a partir do CEP
1 r e q u i r e nc l ua s oa p
2 f u n c t i o n get Res pons e ( r e s u l t )
3 p r i n t ( r e s u l t . nome , r e s u l t . b a i r r o , r e s u l t . ci dade , r e s u l t . UF)
4 end
5
6 l o c a l msg = {
7 a ddr e s s = h t t p : / / www. b r o n z e b u s i n e s s . com. br / we bs e r vi c e s / wscep . asmx ,
8 namespace = h t t p : / / t e mpur i . or g / ,
9 oper at i onName = cep , par ams = { s t r c e p = 70855530 }
10 }
11
12 nc l ua s oa p . c a l l ( msg , get Res pons e )
Algumas aplicac oes foram desenvolvidas como prova de conceito de utilizac ao do
m odulo. Entre elas est ao o rastreamento de encomendas postadas pelos Correios, consulta
de cotac ao do D olar, previs ao do tempo, consulta de endereco a partir do CEP e outras.
5.5.2.1 Testes de Interoperabilidade
Os diversos servicos consumidos pelas aplicac oes apresentadas s ao desenvolvidos em
diferentes linguagens e plataformas. Procurou-se realizar testes com estes diferentes servicos
para vericar a interoperabilidade do NCLua SOAP (um dos requisitos fundamentais, se n ao
o mais importante, para qualquer implementac ao SOAP). Com os testes realizados p ode-se
comprovar a eci encia do m odulo, uma vez que para todos os servicos testados, obteve-se o
retorno esperado, tratando-o de forma padronizada.
No incio, alguns usu arios do f orum do projeto relataram problemas ao utilizar servicos
desenvolvidos em linguagem Java. Os problemas encontrados foram devido aos Web Servi-
ces criados com a API JAX-WS, padr ao da plataforma Java, especicarem os tipos de dados
utilizados pelo servico em um arquivo XSD (XML Schema Denition) externo, no lugar
de especicar diretamente dentro do documento WSDL. Tal caracterstica requer pequenas
mudancas no formato da mensagem SOAP a ser enviada para consumir tais Web Services.
Assim, foi preciso adequar o m odulo para entrar em conformidade com o padr ao SOAP.
Particularidades encontradas em Web Services PHP tamb em foram relatadas e o m odulo
72
foi adequado para permitir a interoperabilidade com tais servicos.

E importante ressaltar
que, no caso de tais servicos PHP, estes foram desenvolvidos utilizando o tookit nuSOAP
6
.
Tal tookit n ao leva em conta os nomes dos par ametros de entrada e sim a ordem dos mes-
mos, n ao estando em conformidade com o padr ao SOAP. Assim, o problema e especco da
implementac ao do nuSOAP, mas que foi contornado pelo NCLua SOAP para evitar quais-
quer transtornos ao consumir Web Services desenvolvidos com tal tookit.
5.6 Ambiente de desenvolvimento
Para o desenvolvimento do projeto foram utilizados:
sistema operacional GNU/Linux Ubuntu 10.10 como sistema desktop para realizac ao
das tarefas de desenvolvimento:
ferramentas telnet e curl para teste de envio de requisic oes HTTP/SOAP geradas
com os m odulos implementados.
soapUI 3.5.1 para testes de consumo de Web Services SOAP;
Astah Community 6.1 (antigo Jude) para modelagem UML;
IDE Eclipse 3.6:
plugin NCLEclipse 1.5.1;
plugin LuaEclipse 1.3.1.
ferramenta LuaDoc
7
para gerac ao de documentac ao;
implementac ao de refer encia do Ginga-NCL (Ginga Virtual Set-top Box 0.11.2):
m odulo tcp.lua
8
para envio de requisic oes TCP;
m odulo LuaXML para tratamento de XML;
m odulo LuaProler
9
para realizac ao das an alises de desempenho, descritas na
Sec ao 5.7.
interpretador Lua para execuc ao do script wsdlparser.lua fora do Ginga Virtual Set-top
Box.
6
http://sourceforge.net/projects/nusoap
7
http://luadoc.luaforge.net
8
http://www.lua.inf.puc-rio.br/
francisco/nclua/
9
http://luaprofiler.luaforge.net
73
5.7 Avaliac ao de Desempenho e Comparac oes
5.7.1 Avaliac ao de Desempenho do NCLua SOAP
Utilizando-se a ferramenta LuaProler (que precisou ter seu processo de compilac ao al-
terado para funcionar em aplicac oes NCLua
10
) foram feitas algumas an alises do desempenho
do NCLua SOAP para avaliar o tempo gasto para gerac ao da requisic ao SOAP. Por meio da
func ao collectgarbage da biblioteca padr ao de Lua, p ode-se vericar o total de mem oria
consumida pelo m odulo.
O percentual de uso da CPU foi obtido por meio da ferramenta top, existente no sistema
operacional do Ginga Virtual Set-top Box. Para a obtenc ao deste percentual, executou-se a
aplicac ao NCL (que n ao inicia o script Lua automaticamente) e vericou-se o uso da CPU
pelo processo de nome ginga(respons avel pela execuc ao das aplicac oes interativas) no
momento em que este se tornava est avel. Em seguida, por meio de um comando na aplicac ao
NCL, o script Lua e ent ao executado, gerando e enviando a requisic ao SOAP. Ap os isto,
vericou-se o pico de uso do processador, considerando que os scripts Lua testados somente
enviam a requisic ao SOAP e exibem o retorno no terminal. Com a diferenca entre o pico
de uso do processador depois da execuc ao do script e o valor observado antes do incio do
mesmo, obt em-se o percentual de uso do processador pelo NCLua SOAP.
A Tabela 5.1 apresenta os resultados obtidos para algumas das aplicac oes testadas.
Web Service consumido Par ametros
de entrada
Tempo de gerac ao da
requisic ao:
chamada ao m etodo
call (em segundos)
Uso de
Mem oria
RAM
(em KB)
% de Uso
da CPU
Situac ao do tempo
http://www.deeptraining.
com/webservices/weather.
asmx
City = Braslia 0.13 121.78 0.3
Convers ao de Moeda
http://www.webservicex.
net/CurrencyConvertor.asmx
FromCurrency = USD
ToCurrency = BRL
0.13 121.65 0.3
Consulta de endereco a partir do CEP
http://www.maniezo.com.br/
webservice/soap-server.php
cep = 77021682 0.13 133.17 0.3
Tabela 5.1: Avaliac ao de Desempenho do NCLua SOAP
Como pode ser observado na Tabela 5.1, o tempo para gerac ao da requisic ao, ou seja,
a chamada ao m etodo call do m odulo, na implementac ao de refer encia do Ginga (Ginga
Virtual Set-top Box, vers ao 0.11.2) est a em torno de 0.13 segundo. O m etodo call inclui a
convers ao dos dados passados em uma tabela Lua para o formato XML para serem envia-
dos ao Web Service. Tal m etodo n ao aguarda a conex ao ao servidor Web e nem o envio e
resposta da requisic ao, pois tais operac oes s ao assncronas no Ginga-NCL. Assim, o tempo
10
http://goo.gl/42CQA
74
de execuc ao do m etodo call reete apenas o tempo de gerac ao da requisic ao SOAP. Os tem-
pos obtidos nos testes n ao variaram muito, e a variac ao vai depender apenas do total de
par ametros passados.
O uso de mem oria RAM tamb em cou baixo, em torno de 120KB, que varia de acordo
com os par ametros de entrada e sada do m etodo remoto.
Em todos os exemplos executados, p ode-se observar que o percentual de uso da CPU se
manteve est avel em 0.3%, sendo um valor consideravelmente baixo.
Foram feitas an alises do uso direto do m odulo tcp.lua para vericar o overhead causado
pelo NCLua SOAP, que e uma camada sobre o tcp.lua. Nos tr es exemplos apresentados na
Tabela 5.1, o tempo de uso da CPU se manteve tamb em est avel e igual aos valores obtidos
com o NCLua SOAP, 0.3%. N ao foram feitas medidas quanto ao tempo gasto (em segundos)
para gerac ao da requisic ao, pois, para uso direto do tcp.lua, o desenvolvedor precisa passar
ao m odulo uma string j a com a requisic ao SOAP formatada. Assim, n ao h a um delay para
gerac ao da requisic ao pois o tcp.lua recebe a mesma pronta para envio (o que e bastante
complicado para o desenvolvedor gerar manualmente tal requisic ao HTTP/SOAP, al em de
ser totalmente inexvel).
Quanto ao consumo de mem oria RAM, o uso direto do tcp.lua permite uma otimizac ao
neste sentido, uma vez que a quantidade de var aveis e estruturas de dados declaradas e muito
menor, considerando que o m odulo deve receber a requisic ao pr e-formatada. Para o primeiro
exemplo da Tabela 5.1, a aplicac ao consumiu 76.02 KB de mem oria RAM, para o segundo
consumiu 75.59 KB e para o terceiro exemplo consumiu 66.28 KB. Tais valores mostram
que o consumo de mem oria est a em torno de 50% do consumido pelo NCLua SOAP.
Foram feitas aplicac oes para consumir os mesmos Web Services apresentados na Tabela
5.1 utilizando o m odulo LuaSOAP. No entanto, a aplicac ao funcionou apenas para o Web
Service de obtenc ao de endereco a partir do CEP, que implementa o SOAP 1.1. Para os outros
Web Services testados, que implementam SOAP 1.2, o LuaSOAP n ao enviou a requisic ao
no formato esperado e os Web Services retornaram mensagens de erro. O LuaSOAP e um
projeto que n ao tem atualizac oes desde 2004, assim, tais problemas eram esperados. Com o
Web Service de busca de endereco, a aplicac ao consumiu 139.20KB de mem oria RAM, cerca
de 6KB a mais que com o NCLua SOAP. O tempo de gerac ao da requisic ao foi de apenas
0.01 segundo, bem inferior ao do NCLua SOAP, que levou 0.13 segundo. Presume-se que
este tempo reduzido gasto pelo LuaSOAP e devido ao mesmo utilizar m odulos escritos em
C, que por serem compilados, t em este ganho de desempenho.
Quanto ao uso de CPU, a aplicac ao com o LuaSOAP teve pico de 1.0%, sendo que com o
NCLua SOAP este percentual foi de apenas 0.3. Presume-se que tal valor elevado e devido ao
fato de uso do parser XML Expat, que e uma implementac ao mais completa que o LuaXML
usado no NCLua SOAP.
Com tais valores apresentados anteriormente, considera-se que o NCLua SOAP e bas-
tante eciente em quest oes de tempo de processamento e uso de mem oria. Presume-se que
75
o tempo de processamento pode ser reduzido em um hardware dedicado como o dos Set-
top Boxes, pois os testes foram realizados em uma sistema operacional Linux com v arias
aplicac oes em execuc ao e em uma m aquina virtual (cujo desempenho e inferior a de uma
m aquina real com nalidades especcas).
5.7.2 Comparativo entre os m odulos implementados e o uso direto do
m odulo tcp.lua
Nesta sec ao e feito umcomparativo entre aplicac oes desenvolvidas utilizando os m odulos
implementados e o uso direto do m odulo tcp.lua[SantAnna 2010].
O NCLua SOAP, juntamente como o NCLua HTTP, encapsulam toda a complexidade
de envio de requisic oes SOAP por meio do protocolo HTTP, facilitando a utilizac ao de tais
protocolos em aplicac oes de TVDi. A quantidade de c odigo necess aria para a realizac ao de
requisic oes HTTP ou SOAP e bastante reduzida com os m odulos implementados, permitindo
uma maior agilidade no desenvolvimento de aplicac oes, al em de minimizar a possibilidade
de erros e reduzir a duplicac ao de c odigo.
A Tabela 5.2 apresenta um comparativo do total de linhas existentes em aplicac oes uti-
lizando os m odulos desenvolvidos e outras que n ao os utilizam, mostrando como o c odigo
das aplicac oes e reduzido com o uso dos m odulos implementados. A utilizac ao dos m odulos
no desenvolvimento de aplicac oes, al em de reduzir o c odigo das mesmas, libera o desen-
volvedor da necessidade de conhecer detalhes de implementac ao dos protocolos HTTP e
SOAP. Sem a utilizac ao do m odulo tcp.lua, com o uso direto da classe de eventos tcp do
Ginga-NCL, o c odigo das aplicac oes aumentaria substancialmente, em torno de 100 linhas
de c odigo.
Aplicac ao/Protocolo Sem m odulos implementados Com m odulos implementados
Enquete/HTTP 14 linhas de c odigo
5 func oes utilizadas diretamente
5 linhas de c odigo = 35% do anterior
1 func ao usada diretamente
Cotac ao do d olar/SOAP 64 linhas de c odigo
5 func oes utilizadas diretamente
15 linhas de c odigo = 23% do anterior
(9 s ao par ametros do WS) 1 func ao usada diretamente
Tabela 5.2: Comparativo entre aplicac oes de TVD sem e com os m odulos implementados
5.7.3 Comparativo entre o NCLua SOAP e outras implementac oes
A Tabela 5.3 apresenta um comparativo entre alguns toolkits SOAP e o NCLua SOAP.
76
Caractersticas Axis Axis2 PHP gSOAP NCLua SOAP
Linguagem Java Java PHP 5 C++ NCLua
SOAP 1.1 Sim Sim Sim Sim Sim
SOAP 1.2 Sim Sim Sim Sim Sim
SOAP com Anexos Sim Sim Sim Sim Ainda n ao
Gerac ao de c odigo cliente a partir do WSDL Sim Sim Sim Sim Ainda n ao
Suporte para formato document/literal Bom Bom M edio Bom Bom
Requisitos de runtime JVM JVM PHP engine Nenhum Ginga-NCL
Documentac ao Boa Pequena M edia Boa M edia
Tabela 5.3: Comparac ao entre NCLua SOAP e outros toolkits SOAP (adaptada de
[Louridas 2006]).
Como pode ser observado na Tabela 5.3, o NCLua SOAP s o n ao possui dois dos recursos
encontrados nos outros toolkits: suporte a anexos e gerac ao de c odigo cliente a partir do
WSDL. O uso de anexos n ao e algo comumente encontrado nos Web Services disponveis na
Web e com os quais foram feitos testes de interoperabilidade. A falta de gerac ao autom atica
de c odigo cliente a partir do WSDL n ao inviabiliza o uso do m odulo, pois tal c odigo pode
ser escrito pelo desenvolvedor que desejar consumir algum servico, obtendo manualmente
as informac oes necess arias no WSDL. No entanto, considera-se que tal recurso facilitar a
bastante o uso do m odulo.
5.8 Limitac oes do m odulo NCLua SOAP
A atual vers ao do NCLua SOAP possui algumas limitac oes, que entendemos n ao intere-
ferirem no uso do mesmo:
necessidade de o desenvolvedor saber a vers ao do protocolo SOAP do servico que ele
deseja consumir;
necessidade de extrair manualmente alguns dados como o namespace do servico;
falta de tratamento de erros retornados pelo protocolo HTTP, o que causar a comporta-
mentos inesperados na aplicac ao;
necessidade de saber se o servico utiliza um arquivo XML Schema Denition (XSD)
externo, para poder indicar isto no momento da chamada ao m etodo remoto;
n ao permitir o envio de anexos em formato Multipurpose Internet Mail Extensions
(MIME)[IETF 1996] dentro de uma mensagem SOAP.
77
Captulo 6
Conclus oes e Trabalhos Futuros
6.1 Conclus oes
As implementac oes apresentadas nesta dissertac ao s ao todas originais, por n ao haver ne-
nhuma outra implementac ao (pelo menos de c odigo aberto) para o sub-sistema Ginga-NCL
dos protocolos HTTP e SOAP, de um framework de componentes gr acos e de aplicac oes
de T-Commerce. Tais implementac oes permitem o desenvolvimento de aplicac oes dos mais
variados tipos para o Ginga-NCL, alavancando o desenvolvimento de aplicac oes interativas
para o SBTVD (ISDB-TB).
Os m odulos NCLua HTTP e NCLua SOAP facilitam a converg encia entre Web e TV,
escondendo os detalhes de implementac ao dos protocolos HTTP e SOAP do desenvol-
vedor de aplicac oes de TVDi, permitindo o surgimento de novas aplicac oes interativas
que fazem uso de conte udo da Internet. O NCLua SOAP permitiu o desenvolvimento de
aplicac oes de T-Government como apresentado em [Barbosa, Kutiishi e Lima 2010], en-
tre outras. Na p agina do projeto, em http://ncluasoap.manoelcampos.com e
em http://labtvdi.unb.br, existe um link para o f orum de discuss ao do m odulo,
onde alguns usu arios relatam a utilizac ao do mesmo, por exemplo, em aplicac oes de
recomendac ao de conte udo e T-Learning.
Atualmente, o processo de obtenc ao dos dados para realizar a chamada a um m etodo
remoto em um Web Service ainda e praticamente todo manual, no entanto, ap os o desenvol-
vedor obter tais dados para o m etodo remoto desejado, a realizac ao da requisic ao e bastante
simplicada, principalmente pelo fato de Lua ser uma linguagem de tipagem din amica, n ao
obrigando a declarac ao de vari aveis com seus respectivos tipos. O feedback dos usu arios
tem mostrado que o m odulo est a sendo bastante util para a comunidade, al em de permitir a
evoluc ao do mesmo.
A arquitetura proposta serve de base para o desenvolvimento de servicos de T-Commerce
para o SBTVD, mostrando como diversos servicos podem ser integrados em uma unica ar-
quitetura para um prop osito nal. Tal arquitetura tamb em serve como um estudo de caso
78
dos percalcos enfrentados para a elaborac ao de um ambiente de desenvolvimento e testes de
aplicac oes para o SBTVD, mostrando as ferramentas necess arias para isto.
As an alises de desempenho apresentadas dos protocolos implementados mostraramcomo
a soluc ao proposta e eciente em uso de processador e mem oria RAM, sendo uma soluc ao
ideal para uso em ambientes restritos de recursos, como os Set-top Boxes.
Os protocolos implementados s ao a base da integrac ao entre Web e TV e est ao sendo
bastante uteis em diversos outros trabalhos, como apresentado no Captulo 5, mostrando
como os resultados alcancados se tornaram importantes para a comunidade de TV Digital no
Brasil e na Am erica Latina, onde quase todos os pases j a adotaram o ISDB-TB.
A aplicac ao de T-Commerce desenvolvida delineia o processo de desenvolvimento de
aplicac oes que fogem do trivial, mostrando como aplicar recursos como orientac ao a obje-
tos na linguagem Lua, uso do canal de retorno/interatividade no SBTVD, uso de arquivos
XML e arquivos de dados em formato Lua, al em de outros recursos. O uso do framework
LuaOnTV para construc ao de interfaces gr acas de usu ario e bastante exvel e d a suporte
a m ultiplos dispositivos, adaptac ao autom atica das dimens oes dos componentes gr acos da
aplicac ao, al em do uso de templates para permitir uma denic ao centralizada da identidade
visual da aplicac ao. Tal recurso de templates permite alterar a identidade visual da aplicac ao
facilmente, podendo-se ter templates diferentes para tipos de dispositivos diferentes (como
TVs e celulares).
Outras aplicac oes foram desenvolvidas, como o NCLua RSS Reader e o Rastreador de
Encomendas que servem como prova de conceito dos protocolos como HTTP e SOAP, im-
plementados nesta dissertac ao.
Os objetivos apresentados na Sec ao 1.1 foram todos alcancados, apresentando uma
soluc ao completa, desde o ambiente de desenvolvimento, at e a realizac ao de an alises de
desempenho das aplicac oes desenvolvidas.
A Tabela 6.1 apresenta uma descric ao de como tais objetivos foram alcancados.
79
Objetivo
Especco
Como foi alcancado
A Os requisitos funcionais e n ao funcionais foram elicitados, tendo servido de
guia para o desenvolvimento da arquitetura proposta;
B a arquitetura foi proposta e desenvolvida, apresentando-se a mesma por meio
de guras e diagramas UML, al em da montagem de uma distribuic ao GNU/-
Linux contendo todo o ambiente de desenvolvimento elaborado;
C um framework de comunicac ao de dados foi desenvolvido, composto pelos
m odulos NCLua HTTP e NCLua SOAP, que implementam os protocolos
HTTP e SOAP, respectivamente, sendo a base de toda a interoperac ao das
aplicac oes desenvolvidas com diferentes provedores de servicos Web;
D as diferentes aplicac oes de TVDi propostas foram desenvolvidas e apresenta-
das, servindo como prova de conceito do uso dos frameworks desenvolvidos
ou estendidos;
E o framework LuaOnTV foi estendido, incluindo-se suporte a temas. O re-
curso de temas foi utilizado na aplicac ao de T-Commerce desenvolvida. A
adaptac ao autom atica da interface da aplicac ao foi testada em ambiente vir-
tual de TV Digital (o Ginga Virtual Set-top Box) com diferentes resoluc oes de
tela. Em tal ambiente, a adaptac ao autom atica do tamanho da interface gr aca
da aplicac ao ao tamanho da tela do televisor mostrou-se satisfat oria, possibi-
litando que a aplicac ao de adapte automaticamente a diferentes dispositivos
receptores de TVD;
F um modelo de desenvolvimento de aplicac oes de TVDi baseado em templa-
tes foi elaborado e apresentado. Tal modelo foi utilizado na aplicac ao de T-
Commerce desenvolvida, o que permitiu uma agilidade no desenvolvimento
da mesma, denindo um conjunto de componentes gr acos b asicos e uma
identidade visual comum a todas as telas da aplicac ao desenvolvida.
Tabela 6.1: Objetivos Especcos Alcancados
6.2 Trabalhos Futuros
Como trabalhos futuros, pretende-se concluir a implementac ao do parser autom atico do
documento WSDL e gerac ao de stubs Lua, contendo func oes proxies para realizar a chamada
aos m etodos remotos (semelhante a ferramentas como o wsdl2java
1
, pretende-se transformar
o script wsdlparser em um wsdl2nclua) e incluir tratamento de excec oes para permitir que as
aplicac oes de TVDi possam emitir mensagens amig aveis ao usu ario quando uma requisic ao
HTTP falhar.
O m odulo NCLua HTTP permite que seja utilizado qualquer m etodo HTTP em uma
1
http://ws.apache.org/axis/java/user-guide.html
80
requisic ao, no entanto, apenas os m etodo GET e POST foram testados. Desta forma,
pretende-se realizar testes de conformidade utilizando-se os m etodos HTTP OPTIONS,
HEAD, PUT e DELETE. Pretende-se tamb em implementar mais funcionalidades no m odulo,
como realizar redirecionamentos automaticamente a partir de respostas HTTP como 301 e
302, al em de implementar alguns recursos do HTTP/1.1, como conex oes persistentes.
A arquitetura tamb em pode ser estendida nos pontos a seguir:
incluir suporte a metadados na aplicac ao para que a mesma possa oferecer produtos
vinculados a um programa televisivo, permitindo que a oferta do produto seja mostrada
ao telespectador em momento determinado no arquivo de metadados, utilizando os
recursos de sincronizac ao de mdias existente na linguagem NCL;
estudar a viabilidade e uso do protocolo de autorizac ao Open Authentication (oAuth)
2
,
que e bastante utilizado atualmente em redes sociais, permitindo ao usu ario ter um
login e senha unicos para acesso a diferentes servicos, agilizando o processo de login
(caso o usu ario decida salvar localmente, de forma criptografada, as informac oes de
autorizac ao);
estender a arquitetura para um modelo baseado em descoberta de servicos que pos-
sibilite a integrac ao de diferentes lojas virtuais que implementem a arquitetura aqui
proposta, utilizando recursos como a linguagem BPEL (Business Process Execution
Language) para permitir a composic ao de servicos e tornar tal integrac ao transparente
para aplicac ao de TVDi;
utilizar a extens ao WS-Security[OASIS 2006] para permitir a seguranca na
comunicac ao entre os Web Services e as aplicac oes cliente;
criar ferramenta, para execuc ao do lado da emissora de TV, que permita o envio dos
produtos em oferta via broadcast, possibilitando a usu arios, sem conex ao com a Inter-
net, visualizarem tais produtos na tela de seu equipamento de TVD.
2
http://oauth.net
81
Refer encias Bibliogr acas
[ABNT 2008]ABNT, N. 15606-2. Televis ao digital terrestreCodicac ao de dados e
especicac oes de transmiss ao para radiodifus ao digital Parte 2: Ginga-NCL para receptores
xos e m oveisLinguagem de aplicac ao XML para codicac ao de aplicac oes, 2008.
[Barbosa, Kutiishi e Lima 2010]BARBOSA, R. de C.; KUTIISHI, S. M.; LIMA, V. de. De-
senvolvendo servicos de governo eletr onico multiplataforma para TV interativa utilizando
Web Services. Simp osio Brasileiro de Sistemas Multimdia e Web (WebMedia 2010), 2010.
[Barbosa e Soares 2008]BARBOSA, S. D. J.; SOARES, L. F. G. TV digital interativa no
Brasil se faz com Ginga: Fundamentos, Padr oes, Autoria Declarativa e Usabilidade.
Atualizac oes em Inform atica, p. 105174, 2008.
[Board 2009]BOARD, R. A. RSS 2.0 Specication. Disponvel em: http://www.
rssboard.org/rss-specification. Acessado em: 20 mar. 2009., 2009.
[Braga e Restani 2010]BRAGA, A. M.; RESTANI, G. S. Introduc ao ` a seguranca de
aplicac oes para a TV digital interativa brasileira. Simp osio Brasileiro de Seguranca (SBSeg
2010), 2010.
[CETIC.br 2009]CETIC.BR. Tic Domiclios e Usu arios - Pesquisa sobre o Uso das Tecnolo-
gias da Informac ao e da Comunicac ao no Brasil. Disponvel em: http://cetic.br/
usuarios/tic/. Acessado em: 04 mar. 2010., 2009.
[Chu et al. 2007]CHU, S. C. et al. Evolution of e-commerce Web sites: A conceptual fra-
mework and a longitudinal study. Information & Management, Elsevier, v. 44, n. 2, p.
154164, 2007. ISSN 0378-7206.
[Cooper 1999]COOPER, C. Using expat. Disponvel em: http://www.xml.com/pub/
a/1999/09/expat/. Acessado em: 20 dez. 2010., 1999.
[Costa 2009]COSTA, L. C. de P. Seguranca para o Sistema Brasileiro de Televis ao Digital:
Contribuic oes ` a Protec ao de Direitos Autorais e ` a Autenticac ao de Aplicativos. Dissertac ao
de Mestrado. Escola Polit ecnica da Universidade de S ao Paulo, 2009.
[Coulouris, Dollimore e Kindberg 2007]COULOURIS, G.; DOLLIMORE, J.; KINDBERG,
T. Sistemas Distribudos: Conceitos e Projeto. Porto Alegre, 4a. ed.: Bookman, 2007.
82
[Curbera et al. 2002]CURBERA, F. et al. Unraveling the Web services web: an introduction
to SOAP, WSDL, and UDDI. IEEE Internet computing, v. 6, n. 2, p. 8693, 2002. ISSN
1089-7801.
[Davis e Parashar 2005]DAVIS, D.; PARASHAR, M. Latency performance of SOAP imple-
mentations. In: IEEE. 2nd IEEE/ACM International Symposium on Cluster Computing
and the Grid. [S.l.], 2005. ISBN 0769515827.
[Engelen e Gallivan 2005]ENGELEN, R. A. V.; GALLIVAN, K. A. The gSOAP toolkit for
web services and peer-to-peer computing networks. In: Cluster Computing and the Grid,
2002. 2nd IEEE/ACM International Symposium on. [S.l.: s.n.], 2005. ISBN 0769515827.
[Fern andez e Goldenberg 2008]FERN
ANDEZ, F.; GOLDENBERG, S. Aplicaciones inte-

ractivas para la televisi on digital en Chile. Cuadernos de informaci on, I, n. 22, p. 12, 2008.
[Fielding 2000]FIELDING, R. T. Architectural styles and the design of network-based soft-
ware architectures. PhD Thesis. University of California, Irvine, 2000.
[Fowler 2000]FOWLER, A. A Swing architecture overview. Sun Microsystems, Web-based
Technical Report http://java.sun.com/products/jfc/tsc/articles/
architecture/index.html, 2000.
[G1 2007]G1. TV digital estr eia em S ao Paulo com transmiss ao de emissoras abertas. Dis-
ponvel em: http://g1.globo.com/Noticias/0,,MUL201387-15515,
00-TV+DIGITAL+ESTREIA+EM+SAO+PAULO+COM+TRANSMISSAO+DE+
EMISSORAS+ABERTAS.html. Acessado em: 23 fev. 2011., 2007.
[Ghisi, Lopes e Siqueira 2010]GHISI, B. C.; LOPES, G. F.; SIQUEIRA, F. Integrac ao de
Aplicac oes para TV Digital Interativa com Redes Sociais. Simp osio Brasileiro de Sistemas
Multimdia e Web (WebMedia 2010), 2010.
[IBGE 2009]IBGE. Pesquisa Nacional por Amostra de Domiclios 2009 - PNAD. Disponvel
em: http://www.ibge.gov.br/home/presidencia/noticias/noticia_
visualiza.php?id_noticia=1708. Acessado em 14 fev. 2011, 2009.
[IBGE 2010]IBGE. Censo Brasileiro 2010. Disponvel em: http://www.censo2010.
ibge.gov.br/dados_divulgados/index.php. Acessado em: 25 fev. 2010.,
2010.
[IDGNow 2010]IDGNOW. Ginga, completo, vira padr ao UIT. Disponvel
em: http://idgnow.uol.com.br/blog/circuito/2010/03/24/
ginga-completo-vira-padrao-uit/. Acessado em: 23 fev. 2011., 2010.
[Ierusalimschy 2006]IERUSALIMSCHY, R. Programming in Lua. 2nd. ed. Rio de Janeiro:
Lua.org, 2006. 328 p. ISBN 8590379825.
83
[Ierusalimschy, Carregal e Guisasola 2004]IERUSALIMSCHY, R.; CARREGAL, A.; GUI-
SASOLA, T. LuaSOAP - SOAP interface to the Lua programming language. Disponvel
em: http://www.keplerproject.org/luasoap/. Acessado em: 28 out. 2010.,
2004.
[Ierusalimschy, Figueiredo e Celes 2007]IERUSALIMSCHY, R.; FIGUEIREDO, L. H. de;
CELES, W. The evolution of Lua. In: Proceedings of the third ACM SIGPLAN conference
on History of programming languages. [S.l.: s.n.], 2007.
[IETF 1996]IETF. MIME. Disponvel em: http://tools.ietf.org/html/
rfc2045. Acessado em: 22 jan. 2011., 1996.
[InfoExame 2009]INFOEXAME. Ginga-NCL e aprovado como padr ao mundial para IPTV.
Disponvel em: http://info.abril.com.br/professional/network/
gingancl-e-aprovado-como-padrao-mundial-para-iptv.shtml.
Acessado em: 23 fev. 2011., 2009.
[InterSystems 2010]INTERSYSTEMS. TrackCare Solution Guide. Disponvel em: http:
//www.intersystems.com/trakcare/solution/section-04.html.
Acessado em: 09 mar. 2010., 2010.
[ITU-T 2009]ITU-T. J.201: CABLE NETWORKS AND TRANSMISSION OF TELE-
VISION, SOUND PROGRAMME AND OTHER MULTIMEDIA SIGNALS. Applica-
tion for Interactive Digital Television - Harmonization of declarative content format for
interactive television applications. Disponvel em: http://www.itu.int/itu-t/
recommendations/rec.aspx?id=9583. Acessado em: 25 fev. 2011., 2009.
[ITU-T 2010]ITU-T. J.200: CABLE NETWORKS AND TRANSMISSION OF TELEVI-
SION, SOUND PROGRAMME AND OTHER MULTIMEDIA SIGNALS. Application
for Interactive Digital Television - Worldwide common core Application environment
for digital interactive television services. Disponvel em: http://www.itu.int/
itu-t/recommendations/rec.aspx?id=10827. Acessado em: 25 fev. 2011.,
2010.
[ITU-T 2010]ITU-T. J.202: CABLE NETWORKS AND TRANSMISSION OF TELE-
VISION, SOUND PROGRAMME AND OTHER MULTIMEDIA SIGNALS. Applica-
tion for Interactive Digital Television - Harmonization of procedural content formats
for interactive TV applications. Disponvel em: http://www.itu.int/itu-t/
recommendations/rec.aspx?id=8667. Acessado em: 25 fev. 2011., 2010.
[Johnson e Foote 1988]JOHNSON, R.; FOOTE, B. Designing reusable classes. Journal of
object-oriented programming, Citeseer, v. 1, n. 2, p. 2235, 1988.
[Jr e Waclawek 2007]JR, F. L. D.; WACLAWEK, K. The Expat XML Parser. Disponvel em:
http://www.libexpat.org. Acessado em: 04 fev. 2011., 2007.
84
[J unior e Gondim 2009]J
UNIOR, P. J. S.; GONDIM, P. R. L. LUACOMP: ferramenta de

autoria de aplicac oes para tv digital. Dissertac ao de Mestrado. Universidade de Braslia,
Brasil., 2009.
[KOPECK
Y e Simperl 2008]KOPECK
Y, J.; SIMPERL, E. Semantic web service offer dis-

covery for e-commerce. In: Proceedings of the 10th international conference on Electronic
commerce. [S.l.: s.n.], 2008.
[Lausen e Haselwanter 2007]LAUSEN, H.; HASELWANTER, T. Finding web services. In:
1st European Semantic Technology Conference. [S.l.: s.n.], 2007.
[Louridas 2006]LOURIDAS, P. Soap and web services. Software, IEEE, IEEE, v. 23, n. 6,
p. 6267, 2006. ISSN 0740-7459.
[Monteiro et al. 2010]MONTEIRO, C. de C. et al. Implementac ao de um Set-top Box Vir-
tual para Desenvolvimento e Testes de Aplicac oes para TV Digital Interativa. International
Information and Telecommunication and Technologies Conference (I2TS 2010), 2010.
[Newcomer 2002]NEWCOMER, E. Understanding Web Services: XML, WSDL, SOAP and
UDDI. Addison-Wesley Professional. 1st ed., 2002.
[OASIS 2006]OASIS. OASIS Web Services Security (WSS) TC. Disponvel em: http://
www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss. Aces-
sado em: 04 mar. 2010., 2006.
[OASIS 2007]OASIS. Web Services Business Process Execution Language Version 2.0.
Disponvel em: http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.
0.pdf. Acessado em 02 mar. 2011., 2007.
[Point 2010]POINT, T. SOAP Tutorial. Disponvel em: http://www.
tutorialspoint.com/soap/. Acessado em: 09 mar. 2010., 2010.
[PUC-Rio 2010]PUC-RIO. Comunidade Ginga-NCL. Disponvel em: http://www.
softwarepublico.gov.br/dotlrn/clubs/ginga/. Acessado em: 28 nov.
2010., 2010.
[SantAnna 2010]SANTANNA, F. Documentac ao NCLua. Disponvel em:
http://www.lua.inf.puc-rio.br/ francisco/nclua/. Acessado em: 10 fev. 2010., 2010.
[SantAnna, Cerqueira e Soares 2008]SANTANNA, F.; CERQUEIRA, R.; SOARES, L.
F. G. NCLua: objetos imperativos lua na linguagem declarativa NCL. In: ACM.
Proceedings of the 14th Brazilian Symposium on Multimedia and the Web. [S.l.], 2008.
p. 8390.
[SBTVD 2010]SBTVD, F. O que e o ISDB-TB. Disponvel em: http://www.
forumsbtvd.org.br/materias.asp?id=20. Acessado em: 25 fev. 2011., 2010.
85
[Soares e Barbosa 2009]SOARES, L. F. G.; BARBOSA, S. D. J.
Programando em NCL 3.0: Desenvolvimento de aplicac oes para o middleware Ginga.
[S.l.]: Campus, Rio de Janeiro, 1a. edic ao., 2009.
[Soares, Rodrigues e Moreno 2007]SOARES, L. F. G.; RODRIGUES, R. F.; MORENO,
M. F. Ginga-NCL: the declarative environment of the Brazilian digital TV system. Journal
of the Brazilian Computer Society, SciELO Brasil, v. 12, p. 3746, 2007. ISSN 0104-6500.
[Sommerville 2011]SOMMERVILLE, I. Software Engineering. 9th. ed. [S.l.]: Pearson,
2011.
[Sntese 2010]SNTESE, T. Extra inicia vendas por TV digital. Disponvel em: http://
goo.gl/DuMzD. Acessado em: 23 fev. 2011., 2010.
[Teixeira 2006]TEIXEIRA, L. H. de P. Usabilidade e Entretenimento na TV Digital Intera-
tiva. UNIrevista, v. 1, n. 3, 2006. ISSN 1809-4651.
[TeleTime 2010]TELETIME. Totvs lanca plataforma de aplicativos para TV di-
gital. Disponvel em: http://www.teletime.com.br/23/08/2010/
totvs-lanca-plataforma-de-aplicativos-para-tv-digital/tt/
196493/news.aspx. Acessado em: 14 mar. 2011., 2010.
[Treiber e Dustdar 2007]TREIBER, M.; DUSTDAR, S. Active web service registries. IEEE
Internet Computing, IEEE Computer Society, p. 6671, 2007.
[Veijalainen, Terziyan e Tirri 2006]VEIJALAINEN, J.; TERZIYAN, V.; TIRRI, H. Transac-
tion management for m-commerce at a mobile terminal. Electronic Commerce Research
and Applications, Elsevier, v. 5, n. 3, p. 229245, 2006. ISSN 1567-4223.
[Vilas et al. 2007]VILAS, A. F. et al. Providing Web Services over DVB-H: Mobile Virtual
Web Services. IEEE Transactions on Consumer Electronics, IEEE; 1999, v. 53, n. 2, p. 644,
2007.
[W3C 2007]W3C. SOAP Specication. Disponvel em: http://www.w3.org/TR/
soap/. Acessado em: 04 out. 2009., 2007.
[W3C 2009]W3C. Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specication. Dis-
ponvel em: http://www.w3.org/TR/2009/CR-CSS2-20090908/. Acessado
em: 29 nov. 2010., 2009.
[Welling 2006]WELLING, M. Integration of Interactive Applications in Digital Televi-
sion. Monograa de Bacharelado. EVTEK University of Applied Sciences - Institute of
Technology. Finl andia, 2006.
86
Ap endice A
Screenshots da aplicac ao de T-Commerce
Figura 6.1: Aplicac ao de T-Commerce: Tela inicial com produtos em destaque
87
Figura 6.2: Aplicac ao de T-Commerce: Busca de produtos
Figura 6.3: Aplicac ao de T-Commerce: Login (utilizando e-mail ou CPF)
Figura 6.4: Aplicac ao de T-Commerce: Recuperar senha por e-mail ou SMS
88
Figura 6.5: Aplicac ao de T-Commerce: Cadastro de Clientes (com busca de endereco a partir
do CEP)
Figura 6.6: Aplicac ao de T-Commerce: Cadastro de Enderecos (com busca de endereco a
partir do CEP)
89
Figura 6.7: Aplicac ao de T-Commerce: Selec ao de Enderecos
Figura 6.8: Aplicac ao de T-Commerce: Formas de Pagamento
90
Figura 6.9: Aplicac ao de T-Commerce: Finalizar Compra
91

2011 ManoelCamposSilvaFilho PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

2011 ManoelCamposSilvaFilho PDF

Transféré par

Droits d'auteur :

Formats disponibles

ARQUITETURA ORIENTADA A SERVIC OS

ILIA-DF, 16 DE JUNHO DE 2011.

EMICO SUBMETIDA AO DEPARTAMENTO DE

ETRICA DA FACULDADE DE TECNOLOGIA DA UNIVERSIDADE DE

ILIA, COMO PARTE DOS REQUISITOS NECESS

ARIOS PARA A OBTENC

ILIA, 16 DE JUNHO DE 2011.

E concedida ` a Universidade de Braslia permiss ao para reproduzir c opias desta dissertac ao de

ONICO: E-Commerce, M-Commerce E T-Commerce. . . . 10

ONICO PARA A TV DIGITAL . . . . . . . . . . 27

ODULOS IMPLEMENTADOS E O TCP.LUA . . . . 76

ODULO NCLUA SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

OES E TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Y e Simperl 2008]. Os mesmos s ao instalados na Camada de Aplicac ao, como

ANDEZ, F.; GOLDENBERG, S. Aplicaciones inte-

UNIOR, P. J. S.; GONDIM, P. R. L. LUACOMP: ferramenta de

Y, J.; SIMPERL, E. Semantic web service offer dis-

Vous aimerez peut-être aussi