ARQUITETURA ORIENTADA A SERVIOS PARA COMRCIO ELETRNICO NO SISTEMA BRASILEIRO DE TV DIGITAL

MANOEL CAMPOS DA SILVA FILHO

DISSERTAO DE MESTRADO EM ENGENHARIA ELTRICA DEPARTAMENTO DE ENGENHARIA ELTRICA

FACULDADE DE TECNOLOGIA UNIVERSIDADE DE BRASLIA

UNIVERSIDADE DE BRASLIA FACULDADE DE TECNOLOGIA DEPARTAMENTO DE ENGENHARIA ELTRICA

ARQUITETURA ORIENTADA A SERVIOS PARA COMRCIO ELETRNICO NO SISTEMA BRASILEIRO DE TV DIGITAL

MANOEL CAMPOS DA SILVA FILHO

Orientador: PROF. DR. PAULO ROBERTO DE LIRA GONDIM, ENE/UNB

DISSERTAO DE MESTRADO EM ENGENHARIA ELTRICA

PUBLICAO PPGENE.DM - 439/2011 BRASLIA-DF, 16 DE JUNHO DE 2011.

UNIVERSIDADE DE BRASLIA FACULDADE DE TECNOLOGIA DEPARTAMENTO DE ENGENHARIA ELTRICA

ARQUITETURA ORIENTADA A SERVIOS PARA COMRCIO ELETRNICO NO SISTEMA BRASILEIRO DE TV DIGITAL

MANOEL CAMPOS DA SILVA FILHO

DISSERTAO DE MESTRADO ACADMICO SUBMETIDA AO DEPARTAMENTO DE ENGENHARIA ELTRICA DA FACULDADE DE TECNOLOGIA DA UNIVERSIDADE DE BRASLIA, COMO PARTE DOS REQUISITOS NECESSRIOS PARA A OBTENO DO GRAU DE MESTRE EM ENGENHARIA ELTRICA.

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

BRASLIA, 16 DE JUNHO DE 2011.

FICHA CATALOGRFICA
MANOEL CAMPOS DA SILVA FILHO Arquitetura orientada a servios para comrcio eletrnico no Sistema Brasileiro de TV Digital 2011xv, 107p., 201x297 mm (ENE/FT/UnB, Mestre, Engenharia Eltrica, 2011) Dissertao de Mestrado - Universidade de Braslia Faculdade de Tecnologia - Departamento de Engenharia Eltrica

REFERNCIA BIBLIOGRFICA
MANOEL CAMPOS DA SILVA FILHO (2011) Arquitetura orientada a servios para comrcio eletrnico no Sistema Brasileiro de TV Digital. Dissertao de Mestrado em Engenharia Eltrica, Publicao 439/2011, Departamento de Engenharia Eltrica, Universidade de Braslia, Braslia, DF, 107p.

CESSO DE DIREITOS
AUTOR: Manoel Campos da Silva Filho TTULO: Arquitetura orientada a servios para comrcio eletrnico no Sistema Brasileiro de TV Digital. GRAU: Mestre ANO: 2011

concedida Universidade de Braslia permisso para reproduzir cpias desta dissertao de Mestrado e para emprestar ou vender tais cpias somente para propsitos acadmicos e cientcos. O autor se reserva a outros direitos de publicao e nenhuma parte desta dissertao de Mestrado pode ser reproduzida sem a autorizao por escrito do autor.

____________________________________________________ Manoel Campos da Silva Filho Universidade de Braslia, Faculdade de Tecnologia, Departamento de Engenharia Eltrica, 70910-900, Braslia-DF, Brasil.

Agradecimentos
Gostaria de agradecer primeiramente ao Instituto Federal de Educao, Cincia e Tecnologia do Tocantins (IFTO), instituio onde leciono, por ter me liberado por dois anos para cursar o programa de mestrado em Engenharia Eltrica da Universidade de Braslia; CAPES pela ajuda nanceira durante este perodo; e um agradecimento especial a meus grandes amigos e companheiros (em ordem alfabtica) Cludio Monteiro, Helder Cleber, Leandro Vaguetti, Lilissanne Marcelly, Maurcio Jnior, 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 no menos importante, gostaria de agradecer a meu orientador, o professor Paulo Gondim, por todos os ensinamentos e apoio durante esta jornada.

Resumo
Arquitetura orientada a servios para comrcio eletrnico no Sistema Brasileiro de TV Digital
Esta dissertao descreve uma arquitetura orientada a servios para provimento de comrcio eletrnico 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 servios de diferentes provedores (nas reas de telecomunicaes, logstica e outros) para compor uma estrutura de T-Commerce. Tais servios so desenvolvidos considerando aspectos de interoperabilidade, utilizando o protocolo SOAP, para o qual apresentada uma implementao, 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 aplicao cliente, desenvolvida em NCL e Lua, apresentada como prova de conceito do uso das implementaes dos protocolos e da arquitetura proposta. Tal aplicao utiliza o framework LuaOnTV para a construo da interface grca de usurio 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 aplicaes desenvolvidas a partir dos frameworks construdos, que complementam as funcionalidades da aplicao de T-Commerce, como leitor de RSS e rastreamento de encomendas. A partir do ambiente de desenvolvimento montado para a construo das aplicaes, contendo a implementao de referncia do sub-sistema Ginga-NCL do middleware Ginga, nativamente instalada, foi gerada uma distribuio Linux que permite que tal ambiente seja instalado em qualquer computador ou mquina virtual, para permitir o desenvolvimento de arquitetura semelhante ou extenso 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 languages, is presented as a proof of concept of the protocols implementations and proposed architecture 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

SUMRIO
R ESUMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A BSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 I NTRODUO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 O BJETIVOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 G ERAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.2 E SPECFICOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 J USTIFICATIVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 M ETODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 O RGANIZAO DO T RABALHO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . R EVISO BIBLIOGRFICA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 C OMRCIO E LETRNICO : E-Commerce, M-Commerce E T-Commerce . . . . 2.2 S ISTEMA B RASILEIRO DE TV D IGITAL (SBTVD) . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 A T ECNOLOGIA DE Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 P ROTOCOLOS DE C OMUNICAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 D ESCRIO DE S ERVIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3 D ESCOBERTA DE S ERVIOS COM UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.4 Web Services REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.5 A RQUITETURA O RIENTADA A S ERVIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A RQUITETURA DE COMRCIO ELETRNICO PARA A TV D IGITAL . . . . . . . . . . 3.1 R EQUISITOS DA A RQUITETURA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 A PRESENTAO G ERAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 C ASOS DE U SO DAS F UNCIONALIDADES DA A RQUITETURA . . . . . . . . . . . . . 3.2.2 T ECNOLOGIAS Core DA A RQUITETURA P ROPOSTA . . . . . . . . . . . . . . . . . . . . . . . . 3.3 D ESCRIO DOS C OMPONENTES DE Software DA A RQUITETURA . . . . . . . . 3.4 D IAGRAMA DE D ISTRIBUIO /I MPLANTAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 A MBIENTE DE DESENVOLVIMENTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 D ISTRIBUIO GNU/L INUX P / DESENVOLVIMENTO DE APLICAES . . .
II III

1 3 3 3 5 7 9 10 10 12 14 17 20 25 25 26 27 27 28 32 33 34 46 48 49

F RAMEWORK L UAO N TV 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.1 D ELIMITAO DO P ROBLEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

iv

4.2 4.2.1 4.2.2 5

L UAO N TV 2.0: N OVA VERSO IMPLEMENTADA . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 M ELHORIA DE D ESEMPENHO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 T EMAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 60 60 61 61 62 62 63 65 66 66 67 68 70 70 71 73 74 74 76 76 77

F RAMEWORK DE COMUNICAO DE DADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 I NTEGRAO ENTRE Web E TV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 D ELIMITAO DO P ROBLEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 T ECNOLOGIAS E NVOLVIDAS E T RABALHOS R ELACIONADOS . . . . . . . . . . . . 5.3.1 T ECNOLOGIAS DE Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.2 L UA E OS scripts NCL UA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.3 P ROTOCOLO TCP NO G INGA -NCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.4 I MPLEMENTAES DE SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 P ROPOSTA DE N OVAS I MPLEMENTAES DE HTTP E SOAP. . . . . . . . . . . . . 5.4.1 D ECISES DE P ROJETO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.2 NCL UA HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.3 NCL UA SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5 E XEMPLOS DE U SO E T ESTES DE I NTEROPERABILIDADE . . . . . . . . . . . . . . . . . 5.5.1 E XEMPLOS DE USO DO NCL UA HTTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5.2 E XEMPLOS DE USO DO NCL UA SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6 A MBIENTE DE DESENVOLVIMENTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7 AVALIAO DE D ESEMPENHO E C OMPARAES . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7.1 AVALIAO DE D ESEMPENHO DO NCL UA SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7.2 C OMPARATIVO ENTRE OS MDULOS IMPLEMENTADOS E O TCP. LUA . . . . 5.7.3 C OMPARATIVO ENTRE O NCL UA SOAP E OUTRAS IMPLEMENTAES . 5.8 L IMITAES DO MDULO NCL UA SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

C ONCLUSES E T RABALHOS F UTUROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 6.1 C ONCLUSES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 6.2 T RABALHOS F UTUROS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

R EFERNCIAS B IBLIOGRFICAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 A PNDICE A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 S CREENSHOTS DA APLICAO DE T-Commerce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

LISTA DE FIGURAS
2.1 2.2 2.3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 4.1 4.2 4.3 4.4 5.1 5.2 5.3 6.1 6.2 6.3 6.4 6.5 6.6 6.7 Arquitetura de Aplicao Distribuda (adaptada de [InterSystems 2010])........ 15 Arquitetura conceitual de sistemas orientados a servios............................. 17 Organizao da Especicao do WSDL................................................. 24 Viso Geral da Arquitetura SOA proposta para T-Commerce ....................... Diagrama de Casos de Uso: Funcionalidades providas a desenvolvedores....... Diagrama de Casos de Uso: Funcionalidades providas aos usurios .............. Tecnologias Core da arquitetura de T-Commerce ....................................... Aplicao de T-Commerce: Tela inicial mostrando os produtos em destaque ... Aplicao de T-Commerce: Diagrama de sequncia do processo de compra .... NCLua RSS Reader - Leitor de Notcias para TV Digital ............................ Rastreamento de encomendas pela TVD: Insero do cdigo de rastreamento . Rastreamento de encomendas pela TVD: Situao da entrega da encomenda .. Diagrama de Classes dos Web Services implementados .............................. Diagrama das classes utilizadas internamente pelos WSs implementados ...... Web Service dos Correios: Calculando preo e prazo de entrega de encomenda Arquitetura de T-Commerce: Diagrama de Distribuio/Implantao ............. Novo diagrama de classes do LuaOnTV.................................................. Grco de Mquinas de Estados da classe EventManager ........................... Classes relacionadas ao novo recurso de temas do LuaOnTV ....................... Diagrama de Componentes do LuaOnTV ................................................ 29 32 33 34 36 37 38 39 40 41 42 44 46 57 58 58 59

Diagrama de Mquinas de Estados do Mdulo tcp.lua ................................ 64 Diagrama de Mquinas de Estados do Mdulo tcp.lua (co-rotinas em execuo) 65 Diagrama de Componentes do NCLua SOAP e NCLua HTTP ..................... 70 Aplicao de T-Commerce: Aplicao de T-Commerce: Aplicao de T-Commerce: Aplicao de T-Commerce: Aplicao de T-Commerce: Aplicao de T-Commerce: Aplicao de T-Commerce: Tela inicial com produtos em destaque ............... Busca de produtos ......................................... Login (utilizando e-mail ou CPF)...................... Recuperar senha por e-mail ou SMS .................. Cadastro de Clientes ...................................... Cadastro de Endereos ................................... Seleo de Endereos ..................................... 87 87 88 88 89 89 90

vi

6.8 6.9

Aplicao de T-Commerce: Formas de Pagamento .................................... 90 Aplicao de T-Commerce: Finalizar Compra .......................................... 91

LISTA DE TABELAS
3.1 3.2 4.1 5.1 5.2 5.3 6.1 Requisitos da Arquitetura de T-Commerce ............................................... 28 Requisitos funcionais e no funcionais da aplicao de T-Commerce ............. 35 Requisitos implementados na nova verso do LuaOnTV ............................. 53 Avaliao de Desempenho do NCLua SOAP............................................ 74 Comparativo entre aplicaes de TVD sem e com os mdulos implementados 76 Comparao entre NCLua SOAP e outros toolkits SOAP ............................ 76 Objetivos Especcos Alcanados.......................................................... 80

viii

LISTA DE CDIGOS FONTE

2.1 2.2 2.3 2.4 2.5 2.6 5.1 5.2 5.3 5.4 5.5 Estrutura de um envelope SOAP [Curbera et al. 2002] ............................... Envelope SOAP transportado via HTTP [Curbera et al. 2002]...................... Chamada SOAP RPC empacotada em HTTP [Curbera et al. 2002] ............... Resposta de requisio SOAP empacotada em HTTP [Curbera et al. 2002] .... Fragmento de uma descrio de WSDL [Curbera et al. 2002] ...................... Informaes concretas de ligao em um WSDL [Curbera et al. 2002] .......... Exemplo de tabela Lua gerada a partir do XML de uma resposta SOAP ......... Exemplo de simplicao de retorno de resposta SOAP pelo NCLua SOAP ... Exemplo de envio de requisio GET com NCLua HTTP ........................... Exemplo de consumo de Web Service de previso do tempo ........................ Exemplo de consumo de WS de consulta de endereo a partir do CEP ........... 17 18 19 20 22 23 68 69 70 71 72

ix

LISTA DE TERMOS E SIGLAS

AJAX API ATSC B2B B2C BPEL CASE CEP CETIC.br CGI.br COM+ CORBA CSS DAO DCOM DVB E-Commerce EAI ECT EDI HTML Asynchronous Javascript And XML Application Programming Interface Advanced Television Systems Committee Business-to-Business Business-to-Consumer Business Process Execution Language Computer-Aided Software Engineering Cdigo de Endereamento Postal Centro de Estudos sobre as Tecnologias da Informao e da Comunicao Comit Gestor da Internet no Brasil Component Object Model Plus Common Object Request Broker Architecture Cascade Style Sheets Data Access Objects Distributed Component Object Model Digital Video Broadcast Comrcio Eletrnico Enterprise Application Integration Empresa Brasileira de Correios e Telgrafos Eletronic Data Interchange HyperText Markup Language

HTTP IDE ISDB-T Java EE JAX JAX-WS JDBC JDK JPA JRE JSON LAN LWUIT

HyperText Transfer Protocol Integrated Development Environment Integrated Services Digital Broadcasting Terrestrial Java Enterprise Edition Java API for XML Java API for XML Web Services Java Database Connectivity Java Development Kit Java Persistent API Java Runtime Environment JavaScript Object Notation Local Area Network Light Weight UI Toolkit

M-Commerce Comrcio Mvel MIME MTA NCL NIC.br OO PNBL REST RIA RMI RPC RSS SBTVD SBTVD-T Multipurpose Internet Mail Extensions Mail Transfer Agent Nested Context Language Ncleo de Informao e Coordenao do Ponto BR Orientao a Objetos Plano Nacional de Banda Larga Representational State Transfer Rich Internet Application Remote Method Invocation Remote Procedure Call Really Simple Syndication Sistema Brasileiro de TV Digital Sistema Brasileiro de Televiso Digital Terrestre

SGBD SMS SMTP SOA SOAP SQL STB T-Commerce UBR UDDI UML UMTS URI URL W3C Web, WWW WLAN WS WSDL XML XSD

Sistema Gerenciador de Banco de Dados Short Message Service Simple Mail Transfer Protocol Service Oriented Architecture Simple Object Access Protocol Structured Query Language Set-top Box (Conversor Digital) Comrcio pela TV Digital UDDI Business Registry Universal Description, Discovery and Integration Unied Modeling Language Universal Mobile Telecommunications System Uniform Resource Identier Uniform Resource Locator World Wide Web Consortium World Wide Web Wireless Local Area Network Web Service Web Service Description Language eXtensible Markup Language XML Schema Denition

Captulo 1 Introduo
Nas ltimas dcadas, observou-se uma evoluo gradual das tecnologias da informao, e como desdobramento desse evento, a organizao e o comportamento humano sofreram modicaes. Prova disso so os sistemas de compras pelas redes de computadores, que nos ltimos tempos tiveram um crescimento acelerado. O Brasil, assim como outros pases pelo mundo, possui vrios casos de sucesso de lojas de comrcio eletrnico (E-Commerce)1 . Esse fato se deve comodidade de, a partir de um computador ligado Internet, poder-se realizar compras de bens e servios. Nesse modelo, o usurio tem a facilidade e a liberdade de se usar o tempo que julgar necessrio para avaliar o produto que deseja adquirir, alm de efetuar pesquisas em vrias lojas ao mesmo tempo. Outro fator importante, est na qualidade do atendimento, devido aos atendentes possurem em mos um sistema de informao para prover respostas geis e credenciadas. Assim, o usurio economiza tempo e se exime de problemas naturais da organizao contempornea como: as las, gastos de deslocamento, trnsito e estacionamento. Alm disso, as lojas virtuais possuem sistemas de recomendao de produtos, que com base no perl e nas aquisies habituais do usurio, oferecem produtos incentivando o usurio a utilizar o E-Commerce. Todos esses benefcios so alguns dos fatores de sucesso das maiores lojas de E-Commerce no Brasil e no mundo. A Pesquisa sobre o Uso das Tecnologias de Informao e Comunicao no Brasil/TIC Domiclios em 2009 (ltima divulgada at a data de nalizao desta dissertao)[CETIC.br 2009], realizada pelo Centro de Estudos sobre as Tecnologias da Informao e da Comunicao (CETIC.br) 2 e ao Comit Gestor da Internet no Brasil (CGI.br) mostrou que, de 2008 para 2009, houve um aumento de 8% na consulta a preos de produtos ou servios 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 computador
1 2

www.americanas.com.br, www.submarino.com.br, www.pontofrio.com.br e outros Vinculado ao Ncleo de Informao e Coordenao do Ponto BR (NIC.br)

(contra 25% em 2008) e 25% tinham acesso Internet (contra 18% em 2008). Assim os dados da pesquisa supracitada mostram que, no Brasil, as buscas por produtos e servios na Internet crescente e que gradualmente mais pessoas tm acesso ao comrcio eletrnico. O comrcio eletrnico possui outros suportes alm do computador, tais como o celular e, mais recentemente, a TV digital. A compra de produtos pela TV no algo novo. Atualmente existem at canais especcos para tal atividade, no entanto, o usurio precisa utilizar um outro canal para nalizar o processo de compra. A TV Digital traz a facilidade de permitir que todo este processo seja iniciado e nalizado diretamente do controle remoto da TV, trazendo mais comodidade para os usurios, em uma modalidade denominada T-Commerce. As possibilidades dos recursos de interatividade da TV Digital (TVD) so inmeras, dependendo da criatividade das produtoras de contedo e desenvolvedores de software. Um dos sonhos atualmente possveis com as tecnologias de TVD a compra de produtos que estejam sendo exibidos em um programa de TV convencional, como um tnis, uma bolsa, um quadro, ou qualquer outro. Tendo em vista esta tendncia crescente de provimento de servios nas mais diversas plataformas e o sucesso de vrios servios de comrcio eletrnico no Brasil e no mundo, a presente dissertao descreve uma arquitetura para provimento de comrcio eletrnico pela TV Digital (T-Commerce). A arquitetura proposta composta por diversos servios Web que, juntos, agregam todos os servios que so disponibilizados aos usurios dos sistemas de T-Commerce a serem desenvolvidos a partir de tal arquitetura. Esta arquitetura ento enquadrada como uma Arquitetura Orientada a Servios (Service Oriented Architecture SOA), voltada para o provimento de servios de T-Commerce. Tal arquitetura foi elaborada devido no terem sido encontrados outros trabalhos que tratem de uma proposta de comrcio eletrnico para a TV Digital. Assim, a proposta aqui apresentada serve como base para o desenvolvimento de aplicaes de T-Commerce, visando a popularizao de servios de comrcio eletrnico pelo Sistema Brasileiro de TV Digital. Considerando que o sinal analgico de TV Digital est previsto para ser desligado em 2016, segundo previso do Ministrio das Comunicaes3 , todos os brasileiros que desejarem receber sinal de TV, precisaro de um televisor com conversor integrado ou um conversor para conectar um televisor convencional. Desta forma, sistemas de T-Commerce podem ter um grande alcance. A arquitetura proposta, elaborada a partir de requisitos funcionais e no funcionais, serve de base para a implementao de aplicativos para comrcio eletrnico, para o qual so tambm elicitados requisitos funcionais e no funcionais. Esses aplicativos so 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 aplicao seja alterada.
3

http://goo.gl/nLVnW

A arquitetura e a aplicao de T-Commerce propostas utilizam Web Services para disponibilizar funcionalidades aos usurios. Desta forma, tal proposta vai ao encontro da tambm crescente tendncia de integrao entre Web e TV. Tal integrao possvel por meio de protocolos de comunicao padronizados, como o caso dos protocolos HTTP e SOAP, que neste trabalho so objeto de implementaes especcas. Para esta integrao entre Web e TV, apresenta-se uma proposta de framework de comunicao de dados que possibilita a comunicao entre aplicaes de TV Digital e servios disponveis na Web, o qual tem seu emprego demonstrado no somente por meio de aplicaes de T-Commerce, mas tambm de rastreamento de encomendas, leitor de RSS e outras. Um framework um conjunto de classes que incorporam um projeto abstrato de solues para uma famlia de problemas relacionados[Johnson e Foote 1988]. O mesmo pode ser tambm denominado como arcabouo, estrutura, esqueleto, suporte e outros termos. Alguns dos requisitos do aplicativo de T-Commerce supracitado so contemplados com a extenso do framework LuaOnTV para permitir o uso de temas e a adaptao automtica da interface de usurio da aplicao para diferentes tamanhos de TV ou at mesmo em dispositivos mveis como telefones celulares.

1.1
1.1.1

Objetivos
Geral

Propor e desenvolver uma arquitetura orientada a servios, por meio de Web Services SOAP, para provimento de comrcio eletrnico pela TV Digital, favorecendo a convergncia Web-TV.

1.1.2

Especcos

Como objetivos especcos, prope-se: A) elicitar requisitos funcionais e no funcionais a serem atendidos por uma arquitetura baseada em padres de servios Web, a ser utilizada para comrcio eletrnico via TV Digital; B) propor uma arquitetura de servios de T-Commerce, que atenda aos requisitos citados; C) a partir da arquitetura , implementar um framework para comunicao de dados, baseado nos protocolos HTTP e SOAP, para permitir a comunicao de aplicaes de TV Digital, desenvolvidas nas linguagens NCL e Lua, que permita a interoperao com servios Web;

D) caracterizar o emprego do framework de comunicao de dados para desenvolvimento de aplicaes tais como Leitor de RSS, Rastreador de Encomendas, Cliente de Twitter, Enquete e Quiz; E) estender o framework LuaOnTV[Jnior e Gondim 2009] incluindo recursos de temas para permitir a denio centralizada das caractersticas visuais das aplicaes desenvolvidas, alm de incluir suporte a mltiplos dispositivos com diferentes resolues de tela, como TVs e aparelhos celulares; F) um modelo de desenvolvimento de aplicaes para TV Digital (TVD), de forma que todos os formulrios da aplicao (pginas/telas) tenham um mesmo conjunto de componentes bsicos, permitindo a criao de templates para denir a identidade visual da mesma. Assim, ao ser alterado o template, toda a identidade visual da aplicao dever ser alterada;

1.2

Justicativa

Como o incio das operaes do Sistema Brasileiro de TV Digital (SBTVD) bastante recente, onde a primeira transmisso de sinal digital foi realizada em 2007 na cidade de So Paulo, at a data de elaborao da presente dissertao, s conhecia-se um caso de aplicao 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 usurio utilizando outro canal como a loja virtual (Internet) ou o call center da empresa. Alm disso, tal aplicao de comrcio eletrnico foi desenvolvida para o middleware ByYou (implementao 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 aplicao s executa em tal implementao do middleware Ginga. Como o Brasil possui diversos casos de sucesso no mercado de comrcio eletrnico em larga escala, a disponibilizao de aplicaes de comrcio para TV Digital uma tendncia natural, podendo aumentar consideravelmente as vendas das empresas do ramo, devido grande penetrao do aparelho de TV nos lares brasileiros (cerca de 96%)[IBGE 2009], alm de ser uma nova plataforma de E-Commerce para os usurios. Da falta de uma arquitetura para provimento de comrcio eletrnico para o SBTVD, surgiu este trabalho de dissertao, que apresenta uma proposta de arquitetura orientada a servios (Service Oriented Architecture - SOA) para a estruturao de um ambiente de TCommerce. Considerando que tal arquitetura bastante utilizada para a integrao de sistemas heterogneos, ele vai ao encontro de um dos objetivos do projeto: prover uma arquitetura de T-Commerce que utilize servios Web que, juntos, atuem de forma interopervel com o SBTVD e os padres W3C. Desta forma, como a arquitetura SOA pode, comumente, ser baseada em Web Services SOAP, faz-se necessria a implementao de protocolos como Hypertext Transfer Protocol (HTTP) e Simple Object Access Protocol (SOAP) em que se baseiam as tecnologias relacionadas a SOA, sendo tais implementaes objetivos principais deste trabalho. Com a implementao dos protocolos HTTP e SOAP (onde no se tem conhecimento, at a data de elaborao desta dissertao, de nenhuma implementao de cdigo aberto dos mesmos para o ambiente de TVD) criam-se enormes possibilidades de construo de aplicaes para integrao entre Web e TV, um dos objetivos deste projeto com sua arquitetura de T-Commerce. Como durante as pesquisas observou-se que a falta de implementao de tais protocolos era uma queixa recorrente nos fruns da Comunidade Ginga no Portal do Software Pblico4 e em outros fruns de discusso, a implementao de tais protocolos representa uma grande contribuio para o desenvolvimento do SBTVD. Assim, aps a publicao inicial das implementaes dos protocolos HTTP e SOAP, alguns trabalhos
4

http://www.softwarepublico.gov.br/dotlrn/clubs/ginga/

importantes foram desenvolvidos, como ser apresentado no Captulo 5.

1.3

Metodologia

Para o desenvolvimento da presente dissertao foi feito um levantamento bibliogrco sobre as tecnologias, linguagens, ferramentas e trabalhos relacionados para nortear a implementao da arquitetura e soluo proposta. O projeto, anlise e desenvolvimento da soluo seguiu o processo de desenvolvimento em cascata juntamente com o processo de componentizao[Sommerville 2011]. O processo em cascata foi adotado pois os requisitos estavam bem denidos, havendo pequena probabilidade de mudanas radicais. J o processo de componentizao foi tambm adotado devido ao uso de alguns componentes reutilizveis (como Web Services prprios e de terceiros) realizando a integrao destes diversos componentes. No processo de desenvolvimento em cascata, foram seguidas as seguintes etapas: especicao de requisitos - foram denidos os requisitos funcionais e no funcionais, que so apresentados ao longo do trabalho; projeto - foi adotado o paradigma de Orientao a Objetos (OO), utilizando-se a Unied Modeling Language (UML) para modelagem, com o auxlio de ferramenta CASE (Computer-Aided Software Engineering); implementao - a implementao seguiu o paradigma OO, conforme denido na fase de projeto; testes - foram feitos testes de interoperabilidade/integrao para vericar se os componentes da arquitetura estavam se comunicando conforme o esperado. Optou-se, para o desenvolvimento do projeto, pelo paradigma de orientao a objetos pois o mesmo permite um alto grau de reutilizao de cdigo, tornando o mesmo mais organizado e fcil de manter. Para a comunicao entre os componentes da arquitetura da soluo, foi escolhido o protocolo de comunicao SOAP, uma vez que a aplicao de TV Digital desenvolvida faz parte de uma arquitetura distribuda e precisa realizar comunicao com servidores Web por meio da Internet. Assim, foi preciso usar um protocolo que no tivesse problemas de bloqueio em rewalls. Desta forma, o protocolo SOAP foi escolhido tambm por ser padro do World Wide Web Consortium (W3C). Para as aplicaes de TV Digital, foi escolhido o sub-sistema Ginga-NCL do middleware Ginga do Sistema Brasileiro de TV Digital (SBTVD), devido grande quantidade de documentos, fruns de discusso, ferramentas e exemplos disponveis em relao outra vertente de desenvolvimento utilizando a linguagem Java no sub-sistema Ginga-J. Considerando-se ainda que o Ginga-NCL o nico sub-sistema obrigatrio para dispositivos mveis, isto foi decisivo para a escolha, pois assim, a arquitetura e as aplicaes desenvolvidas podem, em

tese, ser executadas em receptores (conversores/Set-bop Boxes) de TV Digital xos, mveis ou portteis. Com a escolha do Ginga-NCL, foi necessria a implementao do protocolo SOAP para este sub-sistema, utilizando-se a linguagem Lua, uma vez que o primeiro s disponibiliza protocolos at a camada de transporte do modelo OSI/ISO, como o TCP. Com isto, foi necessrio realizar testes de interoperabilidade entre aplicaes 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 a integrao de sistemas heterogneos. Assim, tais testes foram necessrios para garantir esta interoperabilidade. Os requisitos da aplicao foram levantados tomando por base as funcionalidades existentes na grande maioria dos Web sites de comrcio eletrnico disponveis na Internet e bastante difundidos no Brasil. Para a construo da interface de usurio das aplicaes de TV Digital, optou-se pela utilizao do framework LuaOnTV para abstrair as primitivas grcas para renderizao da interface. A mesma foi projetada baseada em recursos de templates, o que permite a personalizao e adaptao automtica para diferentes resolues de tela, tendo sido estendido o LuaOnTV para incluir tais recursos.

1.4

Organizao do Trabalho

O Captulo 2 apresenta uma reviso bibliogrca das tecnologias empregadas e relacionadas ao desenvolvimento do trabalho. O Captulo 3 apresenta a arquitetura de T-Commerce proposta. O Captulo 4 apresenta o Framework LuaOnTV, utilizado na construo das interfaces grcas das aplicaes desenvolvidas. O Captulo 5 apresenta um framework de comunicao de dados, utilizado para a integrao das aplicaes desenvolvidas com servios Web. Por m, o Captulo 6 apresenta as concluses e trabalhos futuros.

Captulo 2 Reviso bibliogrca

2.1 Comrcio Eletrnico: E-Commerce, M-Commerce e TCommerce
No incio da World Wide Web (comumente denominada apenas Web) as primeiras pginas de Internet possuam apenas contedo esttico permitindo pouca ou nenhuma interao do usurio. A Web era apenas um repositrio de informaes. Com a crescente demanda de troca de informaes entre empresas, o advento de padres abertos de comunicao, e a necessidade das mesmas de alcanarem novos clientes e mercados, durante a dcada de 90 comeou a surgir um novo gnero de Web sites: os sites de comrcio eletrnico[Chu et al. 2007]. Tais Web sites possibilitaram a realizao de negcios entre compradores e vendedores e entre vendedores e seus parceiros. Desta forma surgiu o E-Commerce. Este baseado na possibilidade de realizao de transaes de forma eletrnica. Segundo [Veijalainen, Terziyan e Tirri 2006]: "uma transao eletrnica uma venda ou compra de produtos ou servios, entre empresas, familiares, indivduos, governos e outras organizaes pblicas ou privadas, conduzidas por redes mediadas por computador." A troca de informaes entre essas empresas era feita por meio de Eletronic Data Interchange (EDI) (troca eletrnica de informaes), no entanto, isto requeria realizao de acordos entre as organizaes[Chu et al. 2007], o que poderia dicultar tais parcerias. O advento de padres abertos como o XML permitiu a evoluo de tais processos de intercmbio de dados e integrao entre empresas. Atualmente existem diversas empresas consolidadas na rea de comrcio eletrnico. Algumas nasceram na era digital e vendem exclusivamente pela Internet, alcanando novos clientes e mercados nacionais e internacionais.

10

Com a recente popularizao de dispositivos mveis e da Internet sem o como rede de grande abrangncia (por exemplo, utilizando as tecnologias de comunicao mvel de 3a gerao como o Universal Mobile Telecommunications System - UMTS), surgem novas oportunidades para as lojas de comrcio eletrnico. Estas entram em uma nova era, com novas perspectivas de captao de clientes e mercados. Com isto surgem novas tendncias como o denominado Comrcio Mvel (M-Commerce), onde as transaes so feitas utilizando-se dispositivos e redes de acesso mveis, tais como Wireless Local Area Networks (WLANs), redes de telecomunicaes 2G ou 3G, conexes Bluetooth ou infravermelho[Veijalainen, Terziyan e Tirri 2006]. Tais dispositivos mveis permitem que os usurios possam realizar compras em qualquer lugar que eles estejam, at mesmo em suas horas livres, durante o trajeto para o trabalho, ou no horrio de almoo. Desta forma, as lojas virtuais tm um mercado em potencial para aumentar suas vendas. Com o advento dos sistemas de televiso digital interativa e a possibilidade de se ter aplicativos executando juntamente com a programao udio-visual, abre-se um novo mercado para as lojas de comrcio eletrnico: a venda de produtos pela TV. Tais servios de vendas pela TV no so 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 comunicao, como o telefone ou recorrer ao Web site da loja na Internet. Utilizando-se os recursos da TV Digital Interativa, todo o processo de compra pode ser realizado diretamente pelo controle remoto da TV, desde que a mesma esteja conectada Internet. As tecnologias da TV Digital trazem um novo benefcio aos usurios: a possibilidade de comprar produtos a partir de um receptor de TV Digital, caracterizando uma nova modalidade de comrcio eletrnico, denominada T-Commerce. Em pases norte-americanos e europeus, que tm sistemas de TV Digital Interativa h mais tempo que o Brasil, existem algumas empresas disponibilizando solues para a rea de T-Commerce 1 2 3 . No Brasil, apesar de as transmisses de TV Digital terem iniciado somente em 2007 na cidade de So Paulo[G1 2007], em 2010 j h solues iniciais para T-Commerce[Sntese 2010], apesar de a nalizao 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, esperase que a interatividade seja um grande diferencial para o pas. Como o Governo Federal pretende realizar incluso social/digital por meio da TV, de acordo com o Decreto nmero 4.901, de 26 de novembro de 2003, espera-se que a disponibilizao de servios pela TV seja crescente. Um fator importante para a difuso da interatividade no pas a existncia de aparelhos de TV em 96% das residncias[IBGE 2009], tendo grandes possibilidades de
1 2

http://www.ensequence.com/t-commerce http://www.digisoft.tv/applications.html 3 http://www.icuetv.com/ets_platform/applications/t_commerce

11

as aplicaes interativas terem um enorme pblico, considerando ainda as dimenses continentais do Brasil e sua enorme populao de 185.712.713 habitantes, segundo o Censo 2010[IBGE 2010]. Outra medida tomada pelo governo que beneciar a interatividade pela TV Digital a criao do Plano Nacional de Banda Larga (PNBL), por meio do Decreto nmero 7.175, de 12 de maio de 2010, visando prover Internet banda larga, a um custo reduzido, em municpios onde no exista tal servio.

2.2

Sistema Brasileiro de TV Digital (SBTVD)

O Sistema Brasileiro de TV Digital (SBTVD) atualmente o mais avanado 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 havia outros padres de TV Digital no mundo, como o americano ATSC (Advanced Television Systems Committee), o europeu DVB (Digital Video Broadcast) e o japons ISDB-T (Integrated Services Digital Broadcasting Terrestrial), tais estudos concluram que o melhor para o pas seria a adoo do sistema japons ISDB-T, que seria estendido para atender s 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 criao do Frum SBTVD (Frum do Sistema Brasileiro de TV Digital). Tal frum, como menciona o decreto supracitado, tem como atribuies: "a assessoria acerca de polticas e assuntos tcnicos referentes aprovao de inovaes tecnolgicas, especicaes, desenvolvimento e implantao do SBTVD-T". O mesmo foi composto, como cita o decreto: "entre outros, por representantes do setor de radiodifuso, do setor industrial e da comunidade cientca e tecnolgica" Dentre as contribuies do Brasil para a rea de TVD, destaca-se a construo do Ginga4 como padro de middleware para aplicaes interativas e no interativas. O Ginga uma inovao nacional, atuando como responsvel pela execuo e controle do ciclo de vida das
3 4

http://www.forumsbtvd.org.br http://www.ginga.org.br

12

aplicaes interativas, abstraindo o sistema operacional e o hardware para elas, alm de realizar tarefas especializadas como a disponibilizao de Application Programming Interfaces (APIs) para facilitar o desenvolvimento de aplicaes interativas[Soares e Barbosa 2009]. O Ginga composto por dois sub-sistemas: um para a execuo de aplicaes declarativas, denominado Ginga-NCL5 , e outro para execuo de aplicaes procedurais, denominado Ginga-J6 . Aplicaes declarativas so aquelas implementadas utilizando-se uma linguagem declarativa, como XML, de forma no algortmica, apenas declarando elementos que comporo a mesma. Tais linguagens abstraem muitos detalhes do desenvolvedor. Aplicaes procedurais so aquelas implementadas utilizando uma linguagem procedural, como Java, onde o desenvolvedor precisa escrever um algoritmo e especicar cada operao a ser realizada, necessitando de conhecimento em linguagens de programao. O sub-sistema Ginga-NCL permite a construo de aplicaes declarativas por meio da linguagem NCL, a Nested Context Language7 . Esta conhecida como uma linguagem de cola, que permite criar aplicaes declarativas juntando-se diferentes tipos de mdias como imagens, texto, hipertexto (HTML), vdeos e outros. Um de seus principais recursos a sincronizao de mdias, muito importante no contexto de aplicaes interativas. Tal recurso garante que, por exemplo, uma legenda seja sincronizada com um vdeo em exibio, ou que uma imagem aparea depois de determinado tempo que o vdeo iniciou. As aplicaes NCL podem ter seu poder estendido com a incluso de mdias especiais: os scripts Lua8 , conhecidos em aplicaes NCL como NCLua. Tais scripts adicionam caractersticas procedurais s aplicaes NCL. O outro sub-sistema que compe o Ginga o chamado Ginga-J, que permite a construo de aplicaes interativas utilizando a linguagem Java. Os outros padres 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 mquina virtual Java e tal API nos conversores de TV Digital precisam pagar royalities Oracle, empresa que atualmente detm os direitos sobre a marca Java. Com isto, o preo dos conversores encarecido. Alm disto, tal API baseada no toolkit grco AWT, que bastante antigo e no possui componentes com visual bonito e elegante. Devido s questes de pagamento de royalities, o Frum SBTVD decidiu fazer um acordo entre a ento Sun, hoje Oracle, para a denio de uma nova API para ser utilizada pelo SBTVD, a qual foi batizada de JavaDTV9 . Tal API livre de royalities e baseada no toolkit grco LWUIT10 , o Light Weight UI Toolkit. O LWUIT um toolkit que possui componentes bonitos e elegantes e o mesmo utilizado em aplicaes para celulares. Com as contribuies brasileiras, o ISDB-T e o SBTVD-T passaram a compartilhar uma
http://www.gingancl.org.br 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
6 5

13

denominao internacionalmente conhecida como ISDB-TB, onde "B"representa as contribuies 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 - Telecommunication Standardization Sector)[InfoExame 2009][IDGNow 2010]. O Ginga se tornou padro de middleware para TVD, relativo recomendao ITU-T J.200[ITU-T 2010]. Seu sub-sistema declarativo Ginga-NCL se tornou recomendao ITU-T J.201[ITU-T 2009] e seu sub-sistema imperativo Ginga-J se tornou recomendao ITU-T J.202[ITU-T 2010]. Ressalta-se, tambm, a recente normatizao, no mbito do ITU-T, referente a IPTV, conhecida como H.761, baseada fortemente no middleware Ginga e seu sub-sistema GingaNCL. Desta forma, o Ginga pode chegar a novas plataformas que no apenas a TV aberta, e as aplicaes interativas e no interativas desenvolvidas em NCL/Lua para o SBTVD podem tambm ser executados em sistemas de IPTV que adotem o Ginga-NCL.

2.3

A Tecnologia de Web Services

H alguns anos as aplicaes corporativas eram desenvolvidas principalmente em um modelo cliente/servidor de duas camadas, existindo uma aplicao desktop que fazia acesso direto a um banco de dados. Pela natureza destas aplicaes, que precisam ser instaladas em cada computador onde sero executadas, existe um grande esforo para atualizar todos os computadores com novas verses do sistema. Mesmo que haja um processo automatizado para esta atualizao, isto demanda recursos como tempo e largura de banda. Com o avano das tecnologias de comunicao de dados, o avano da Web e suas linguagens de programao e, principalmente, com o advento da tecnologia AJAX, atualmente possvel desenvolver aplicaes de Internet ricas (Rich Internet Applications, RIA) com componentes visuais que vo alm dos componentes bsicos 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 mudana de paradigma desktop para Web vem seguida ainda de outra tendncia: a dos sistemas distribudos. Estes so sistemas que comumente utilizam a arquitetura cliente/servidor, no entanto, so compostos de trs ou mais camadas. Segundo [Sommerville 2011]: "um sistema distribudo uma coleo de computadores independentes que aparece para o usurio como um nico sistema coerente." A Figura 2.1 apresenta uma arquitetura de um sistema distribudo em quatro camadas. As mesmas so descritas a seguir. Camada de Apresentao: pode contar tanto com aplicaes desktop leves, conhecidas como thin client (cliente magro/leve), possuindo apenas uma interface grca que faz

14

acesso a um servidor de aplicao, por meio de chamadas de procedimento remoto; quanto com um browser, que faz acesso a um servidor Web, responsvel por gerar as interfaces HTML. Camada Web: composta por um ou mais servidores Web, responsveis por gerar a interface HTML para os clientes Web. As aplicaes desktop no acessam esta camada, tendo ligao direta com a Camada de Aplicao. Camada de Aplicao: composta por um ou mais servidores de aplicao onde as regras de negcios da aplicao esto implementadas. Desta forma, alteraes na lgica de negcios no requer a atualizao dos clientes. Os servidores de aplicao adicionam tolerncia 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 aplicao, o que garante transparncia e independncia de banco de dados aos clientes.

Figura 2.1: Arquitetura de Aplicao Distribuda (adaptada de [InterSystems 2010]). Segundo [Coulouris, Dollimore e Kindberg 2007], um sistema 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 comunicao de aplicao para aplicao, que utiliza protocolos Web existentes e baseados em padres XML abertos [Curbera et al. 2002]. Eles so a maior tecnologia para publicao de servios na Web e tm signicativa adoo em reas como integrao de aplicaes, computao distribuda de larga escala e cooperao business-to-business (B2B) [KOPECK e Simperl 2008]. Os mesmos so instalados na Camada de Aplicao, como mostrado na Figura 2.1, e proveem um conjunto de padres para acesso a servios pela Internet, 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 so componentes reutilizveis, que as aplicaes, independentemente da linguagem em que foram implementadas, podem utilizar sem se preocupar em como eles foram desenvolvidos [Vilas et al. 2007]. Desta forma, a construo de aplicaes a partir de Web Service segue o processo de desenvolvimento de software conhecido como componentizao, 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 alcanar a interoperabilidade entre aplicaes, usando padres Web (Web standards). Eles usam um modelo de integrao fracamente acoplado para permitir a integrao exvel de sistemas heterogneos em uma variedade de domnios, incluindo Business-to-Consumer (B2C), Business-to-Business (B2B) e Enterprise Application Integration (EAI ) [OASIS 2007]. Pela prpria natureza distribuda da Web, o uso de WSs vem ao encontro da integrao entre aplicaes heterogneas, executando em diferentes plataformas, desenvolvidas por diferentes empresas. Cada vez mais empresas disponibilizam servios, pblicos ou privados, para serem utilizados por terceiros, permitindo a interoperabilidade entre diferentes sistemas. Alm disto, pelo fato de WSs serem transportados, principalmente, por protocolo HTTP, no sofrem com problemas de portas bloqueadas em Firewalls que outras tecnologias, como as mencionadas anteriormente, encontram. Isto facilita ainda mais a integrao entre sistemas hospedados em diferentes redes. Um framework de WSs pode ser dividido em trs reas: protocolos de comunicao, descrio de servios e descoberta de servios [Sommerville 2011], conforme apresenta a Figura 2.2 e as sub-sees seguintes.

16

Figura 2.2: Arquitetura conceitual de sistemas orientados a servios (adaptada de [Sommerville 2011]).

2.3.1

Protocolos de Comunicao

Dada a natureza distribuda e heterognea da Web, mecanismos de comunicao devem ser independentes de plataforma, seguros e leves quanto possvel. A linguagem XML um padro altamente utilizado para codicao e intercmbio de dados entre sistemas, sendo totalmente independente de plataforma. Por esse motivo, a mesma utilizada no protocolo de comunicao usado por WSs. O Simple Object Access Protocol (SOAP), um protocolo padronizado pelo World Wide Web Consortium (W3C), como protocolo de comunicao para WSs. O SOAP um protocolo, 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 um protocolo leve, adequado para comunicao em um ambiente distribudo e descentralizado [Vilas et al. 2007]. Uma mensagem SOAP, tambm denominada "envelope SOAP", composta por um arquivo 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 2 3 4 5 6 7 8 9 10

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP:Header> < ! c o n t e n t o f h e a d e r g o e s h e r e > < / SOAP:Header> <SOAP:Body> < ! c o n t e n t o f body g o e s h e r e > < / SOAP:Body> < / SOAP:Envelope >

17

2.3.1.1

Troca de Mensagens SOAP

Como exemplo para esta seo, vamos utilizar um sistema Web de uma companhia area, 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 area, e assim, fazer todo o processo de registro da passagem dentro do seu prprio sistema. Desta forma, o sistema da empresa de turismo deve enviar um envelope SOAP para o WS disponibilizado pela companhia area, contendo os dados do cliente e dados da passagem a ser adquirida, como data/hora, nmero 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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

POST / t r a v e l s e r v i c e SOAPAction: "http://www.acme-travel.com/checkin" C o n t e n t T y p e : t e x t / xml ; c h a r s e t ="utf-8" C o n t e n t L e n g t h : nnnn <SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP:Body> <et:eTicket xmlns:et= "http://www.acme-travel.com/eticket/schema"> < e t : p a s s e n g e r N a m e f i r s t ="Joe" l a s t ="Smith" / > < e t : f l i g h t I n f o a i r l i n e N a m e ="AA" f l i g h t N u m b e r ="1111" d e p a r t u r e D a t e ="2002-01-01" d e p a r t u r e T i m e ="1905" / > </ et:eTicket> < / SOAP:Body> < / SOAP:Envelope >

Observe que o envelope SOAP da Listagem 2.2 no possui um header. O mesmo um elemento opcional e utilizado para prover informaes especcas da aplicao, como credenciais para acesso ao servio e informaes de cobrana, dentre outras[Point 2010].

2.3.1.2

Chamadas de Procedimento Remoto Usando SOAP

Para que SOAP possa usar RPC para chamar procedimentos remotos, necessrio especicar alguns detalhes para o protocolo RPC, por exemplo: como valores de tipos so transportados entre a representao SOAP (XML) e a representao da aplicao, e vice-versa (para indicar, por exemplo, como deve ser feita a converso de uma classe Java para XML e vice-versa), e

18

 onde as vrias partes do protocolo RPC so transportadas (identicao de objeto, nome da operao e parmetros de entrada e sada). A especicao XML schema do W3C 11 prov uma linguagem padro para denir a estrutura do documento e os tipos de dados da estrutura do XML. Isto , dado um tipo bsico como integer ou um tipo complexo como uma struct, XML schema oferece uma forma padro 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 codicao em XML. Usando este estilo de codicao pode-se produzir uma codicao XML para qualquer tipo de dado estruturado. Parmetros RPC e retornos so especicados usando esta codicao. Usando o mesmo WS da companhia area, a empresa de turismo deseja obter informaes a respeito de um determinado voo. Assim, seu sistema pode enviar um envelope SOAP ao WS da companhia area. O envelope da Listagem 2.3 mostra uma chamada RPC, encapsulada dentro de um envelope SOAP. O envelope permite a invocao do mtodo remoto GetFlightInfo, que recebe dois parmetros: uma string contendo o nome da companhia area, e um inteiro contendo o nmero do voo. Tal mtodo retorna um valor estruturado (uma struct) com dois campos: o nmero do porto de embarque e a situao do voo. No envelope SOAP, a chamada para GetFlightInfo um elemento XML com atributos que incluem informaes sobre a codicao (note a referncia para o XML schema). Os elementos lhos so os argumentos do mtodo: airlineName e ightNumber. Os tipos so denidos no atributo type, onde xsd refere-se as denies 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 mtodo GetFlightInfo passando estes valores. Listagem 2.3: Chamada SOAP RPC empacotada em HTTP [Curbera et al. 2002]
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

POST / t r a v e l s e r v i c e SOAPAction: "http://www.acme-travel.com/flightinfo" C o n t e n t T y p e : t e x t / xml ; c h a r s e t ="utf-8" C o n t e n t L e n g t h : nnnn <SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP:Body> <m:GetFlightInfo xmlns:m ="http://www.acme-travel.com/flightinfo" S O A P : e n c o d i n g S t y l e ="http://schemas.xmlsoap.org/soap/encoding/" x m l n s : x s d ="http://www.w3.org/2001/XMLSchema" x m l n s : x s i ="http://www.w3.org/2001/XMLSchema-instance"> < a i r l i n e N a m e x s i : t y p e ="xsd:string">UL< / a i r l i n e N a m e > < f l i g h t N u m b e r x s i : t y p e ="xsd:int">506< / f l i g h t N u m b e r >
11

http://www.w3.org/XML/Schema

19

16 17 18

</ m:GetFlightInfo> < / SOAP:Body> < / SOAP:Envelope >

A Listagem 2.4 mostra a resposta requisio SOAP enviada anteriormente. Neste caso, a resposta contm um valor estruturado, com os campos gate (nmero do porto de embarque) e status (situao do voo). Implementaes de SOAP existem para diversas linguagens, como C/C++, Java, Perl e Lua12 , que automaticamente geram e processam mensagens SOAP. Assumindo que as mensagens esto em conformidade com as especicaes do protocolo SOAP, elas podem ser trocadas por servios implementados em diferentes linguagens e plataformas, permitindo uma total interoperabilidade entre sistemas heterogneos, algo que no sempre verdade para sistemas que utilizam a arquitetura CORBA, que possui objetivos semelhantes ao SOAP. Listagem 2.4: Resposta de requisio SOAP empacotada em HTTP [Curbera et al. 2002]
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

HTTP / 1 . 1 200 OK C o n t e n t T y p e : t e x t / xml ; c h a r s e t ="utf-8" C o n t e n t L e n g t h : nnnn <SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP:Body> <m:GetFlightInfoResponse xmlns:m ="http://www.acme-travel.com/flightinfo" S O A P : e n c o d i n g S t y l e ="http://schemas.xmlsoap.org/soap/encoding/" x m l n s : x s d ="http://www.w3.org/2001/XMLSchema" x m l n s : x s i ="http://www.w3.org/2001/XMLSchema-instance"> <flightInfo> < g a t e x s i : t y p e ="xsd:int">10< / g a t e > < s t a t u s x s i : t y p e ="xsd:string">ON TIME< / s t a t u s > </ flightInfo> </ m:GetFlightInfoResponse> < / SOAP:Body> < / SOAP:Envelope >

2.3.2

Descrio de Servios

O protocolo SOAP dene uma linguagem padro para uso de WSs, mas ele no informa quais mensagens devem ser trocadas para que tenhamos sucesso no uso de um determinado servio. Para isto, existe a Web Service Description Language (WSDL), uma linguagem tambm baseada em XML. Um documento WSDL descreve a interface de um WS, permitindo que as aplicaes que consumiro o servio disponibilizado saibam quais informaes
Uma implementao do protocolo SOAP foi feita para uso em aplicaes de TV digital desenvolvidas em NCL e Lua, e ser apresentada no Captulo 5.
12

20

devem incluir dentro de um envelope SOAP, para chamar um determinado procedimento remoto, disponibilizado pelo WS. O WSDL descreve um WS como uma coleo de end points que podem trocar certas mensagens [Curbera et al. 2002]. Um end point um elemento no WSDL que dene a ligao entre a denio de um determinado servio e o seu endereo de rede, permitindo o acesso ao mesmo. As mensagens SOAP anteriormente mostradas no poderiam ter sido construdas se no conhecssemos o documento WSDL que descreve o servio que desejamos utilizar. Informaes como o nome do mtodo a ser acessado e o nome e tipos dos parmetros de entrada e sada foram obtidos a partir do WSDL do servio [Curbera et al. 2002]. Um servio completo de descrio WSDL prov dois pedaos de informao: uma descrio do servio em nvel de aplicao, ou interface abstrata, e detalhes especcos dependentes do protocolo, que os usurios devem seguir para acessar o servio em end points concretos [Curbera et al. 2002].

2.3.2.1

Descrio de um Web Service

Um documento WSDL dene uma descrio abstrata de um servio, em termos de troca de mensagens em uma interao com o mesmo. Existem trs principais componentes desta interface abstrata: o vocabulrio, a mensagem e a interao. Acordo para uso de um determinado vocabulrio a fundao para qualquer tipo de comunicao. Um WSDL usa sistemas de tipos externos para prover denio de tipos de dados para troca de informaes. Embora o WSDL possa suportar qualquer sistema de tipos, a maioria dos servios 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 denies XSD externas usando um elemento import, especicando sua localizao [Curbera et al. 2002]. O WSDL dene elementos message contendo partes, cada qual descrita por tipos XSD ou elementos de um vocabulrio pr-denido. Cada message prov uma denio de dados tipados e abstratos enviados e recebidos pelos servios. Uma mensagem pode ser de entrada (input), denindo o tipo do(s) parmetro(s) que uma determinada funo deve receber; ou de sada (output), indicando o(s) tipo(s) de valor(es) a ser(em) retornado(s) pela funo, como pode ser visto na Listagem 2.5 [Curbera et al. 2002]. Os elementos portType e operation combinam mensagens para denir iteraes. Cada operation representa um padro de troca de mensagens suportado pelo WS. Cada operation uma combinao de mensagens rotuladas como input (entrada), output (sada) ou fault (falha), para indicar o papel de cada mensagem em uma iterao [Curbera et al. 2002]. Um portType uma coleo de operaes que so coletivamente suportadas por um end point (port). No exemplo da Listagem 2.5, AirportServicePortType descreve duas operaes: uma nica operao no estilo request-response, GetFlightInfo, que espera uma mensa-

21

gem GetFlightInfoInput como entrada e retorna uma mensagem GetFlightInfoOutput como resposta; e uma operao uni direcional, CheckIn, que apenas recebe uma mensagem CheckInInput como entrada [Curbera et al. 2002]. Listagem 2.5: Fragmento de uma descrio de WSDL [Curbera et al. 2002]
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

< m e s s a g e name="GetFlightInfoInput"> < p a r t name="airlineName" t y p e ="xsd:string" / > < p a r t name="flightNumber" t y p e ="xsd:int" / > < / message> < m e s s a g e name="GetFlightInfoOutput"> < p a r t name="flightInfo" t y p e ="fixsd:FlightInfoType" / > < / message> < m e s s a g e name="CheckInInput"> < p a r t name="body" e l e m e n t ="eticketxsd:Ticket" / > < / message> < p o r t T y p e name="AirportServicePortType"> < o p e r a t i o n name="GetFlightInfo"> < i n p u t m e s s a g e ="tns:GetFlightInfoInput" / > < o u t p u t m e s s a g e ="tns:GetFlightInfoOutput" / > </ operation> < o p e r a t i o n name="CheckIn"> < i n p u t m e s s a g e ="tns:CheckInInput" / > </ operation> < / portType>

2.3.2.2

Informaes de Binding

A especicao do WSDL apresenta trs tipos de informaes sobre o servio[Sommerville 2011]: quais operaes o servio suporta (chamado de interface); como mapear as interfaces abstratas para um conjunto de protocolos concretos (binding), e onde est a implementao dos mtodos suportados pelo servio (o endereo de rede). Por meio do binding temos a resposta para o "como", incluindo o protocolo de comunicao e especicao de formato de dados para um completo elemento portType. Sucintamente, o elemento binding diz como dada interao ocorre sobre o protocolo especicado. A Listagem 2.6 mostra um fragmento para o exemplo citado. O binding descreve como usar SOAP para acessar o servio travelservice. Em particular, o documento WSDL mostra que:

22

 GetFlightInfo usar interaes em estilo SOAP-RPC, em que todas as trocas de mensagens usam codicao padro SOAP, e CheckIn uma interao de mensagem pura (chamada de orientada a documento em termos de WSDL), em que o corpo do envelope SOAP contm a mensagem codicada, sem nenhuma codicao de tipo adicional; isto , 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 marshalling13 , promovendo a ligao (binding) desses elementos para permitir o acesso aos mtodos do servio. Um elemento port descreve um nico end point como uma combinao de um binding e um endereo de rede. Consequentemente, um elemento service pode agrupar um conjunto de ports relacionados. Listagem 2.6: Informaes concretas de ligao em um WSDL [Curbera et al. 2002]
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

< b i n d i n g name="AirportServiceSoapBinding" t y p e ="tns:AirportServicePortType"> <soap:binding t r a n s p o r t ="http://schemas.xmlsoap.org/soap/http" / > < o p e r a t i o n name="GetFlightInfo"> < s o a p : o p e r a t i o n s t y l e ="rpc" s o a p A c t i o n ="http://acme-travel/flightinfo" / > <input> < s o a p : b o d y u s e ="encoded" n a m e s p a c e ="http://acme-travel.com/flightinfo" encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/" / > </ input> <output> < s o a p : b o d y u s e ="encoded" n a m e s p a c e ="http://acme-travel.com/flightinfo" encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/" / > </ output> </ operation> < o p e r a t i o n name="CheckIn"> < s o a p : o p e r a t i o n s t y l e ="document" s o a p A c t i o n ="http://acme-travel.com/checkin" / > <input> < s o a p : b o d y u s e ="literal" / > </ input> </ operation> </ binding>

13 Processo de organizar dados em computador, de forma padronizada, para permitir que diferentes aplicaes possam utilizar tais dados, garantindo a interoperabilidade.

23

31 32 33 34 35 36 37

< s e r v i c e name="travelservice"> < p o r t name="travelservicePort" b i n d i n g ="tns:AirportServiceSoapBinding"> <soap:address l o c a t i o n ="http://acmetravel.com/travelservice" / > </ port> </ service>

A Figura 2.3 mostra como a especicao do WSDL organizada. A seo Introduo do WSDL contm a declarao dos Namespaces XML contendo as denies de tipos padres usados pelo Web Service. A seo Interface Abstrata apresenta os tipos denidos pelo Web Service, as declaraes de interfaces (os portTypes) e as mensagens suportadas (como mensagens com os parmetros de entrada a serem enviadas a um mtodo no Web Service e as mensagens de sada com o retorno do mtodo). A seo Implementao Concreta contm as informaes de binding (como o protocolo a ser utilizado na troca de mensagens) e os end points (as interfaces concretas para realizao da vinculao da aplicao cliente com o endereo de rede do Web Service.

Figura 2.3: Organizao da Especicao do WSDL[Sommerville 2011].

2.3.2.3

Usando o WSDL

Para usurios e desenvolvedores, o WSDL prov uma descrio formal das interaes cliente/servidor. Desenvolvedores podem usar o documento WSDL como entrada para uma aplicao que gere funes proxy14 , utilizadas no cliente, para acesso aos mtodos do WS. Tais funes proxy tambm podem ser geradas dinamicamente, em tempo de execuo, por rotinas implementadas no cliente que interpretam o WSDL e geram as chamadas SOAP necessrias. Em ambos os casos, as funes proxy tm a nalidade de esconder do cliente toda a complexidade envolvida no processo de chamada dos mtodos remotos.
Tais funes proxy so escritas ou geradas na linguagem utilizada pela aplicao cliente (que consome o Web Service) e possuem a mesma assinatura dos mtodos remotos, tornando transparente para o cliente a chamada aos mtodos no WS, sendo responsveis por gerar o envelope SOAP para enviar ao servidor onde o WS hospedado.
14

24

2.3.3

Descoberta de Servios com UDDI

As especicaes do Universal Description, Discovery and Integration (UDDI) oferecem aos usurios uma forma sistemtica e unicada para encontrar provedores de servios atravs de um registro centralizado de servios, que , grosseiramente, equivalente a uma "lista telefnica"automatizada online de WSs [Curbera et al. 2002]. O UDDI Business Registry (UBR), acessvel por meio de um browser, foi disponibilizado pouco tempo aps a especicao se tornar pblica, no entanto, o mesmo foi descontinuado em 200515 [Treiber e Dustdar 2007]. Segundo [Sommerville 2011], o padro UDDI no foi amplamente adotado. UDDI prov dois tipos bsicos de especicao que denem a estrutura e operao do registro de servios [Curbera et al. 2002]: uma denio da informao para prover sobre cada servio, e como codic-la; e uma API de busca e atualizao para o registro, que descreve como esta informao pode ser acessada e atualizada. O acesso ao registro realizado usando uma API SOAP para busca e atualizao.

2.3.4 Web Services REST

Como visto anteriormente, SOAP o padro W3C para Web Services, amplamente utilizado na integrao de aplicaes heterogneas. No entanto, existe uma outra vertente para construo de Web Services denominada REST. O REST o acrnimo para Representational State Transfer. Ele um estilo arquitetural para construo de aplicaes distribudas que tambm permite a integrao de aplicaes heterogneas, mas no um padro W3C. O estilo REST foi apresentado pela primeira vez no trabalho de dissertao de Roy Fielding[Fielding 2000], sendo baseado em padres Web como HTTP e URL. Ele consiste em prover servios Web a partir de um recurso Web acessvel por meio de uma URL. A interao com tal servio feita por meio de uso dos mtodos HTTP como GET, POST e DELETE para passagem de parmetros ao servio. Tal estilo bastante simplicado em relao ao SOAP, pois todos os dados a serem passados ao servio vo diretamente na URL do mesmo, por meio de uma requisio HTTP. Desta forma, o tamanho de uma requisio REST bastante reduzido em relao ao SOAP. REST no dene um padro de formato das mensagens de resposta, no entanto, podese perfeitamente utilizar XML para isto. Atualmente outros padres de formato de dados so bastante utilizados como o JavaScript Object Notation (JSON). Desta forma, pode-se utilizar qualquer padro 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 til em aplicaes 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 padro de fato e amplamente utilizado para integrao de servios Web com aplicaes de diferentes tipos, como o caso dos servios disponibilizados pelo microblog Twitter. Este permite que desenvolvedores construam aplicaes nas mais diferentes plataformas (Web, desktop, mobile) que se integrem com o servio de microblog. O REST tambm segue a arquitetura cliente/servidor usada no protocolo SOAP. Segundo [Welling 2006], o estilo denominado REST (em portugus, Transferncia de Estado Representacional), pois o cliente obtm uma representao de um recurso atravs de uma URL, o que faz com que a aplicao cliente entre em um determinado estado. O cliente pode selecionar um link que foi includo no primeiro recurso para, por exemplo, obter informaes detalhadas. Como o link direciona para outro recurso, a aplicao cliente obtm uma nova representao de um recurso e entra em um novo estado. Como citado, a grande vantagem do REST sua simplicidade, no entanto, por no haver um padro de passagem de parmetros e formato de dados para a respostas das requisies, tal estilo pode no ser adequado para a construo de aplicaes seguindo o padro de arquitetura orientada a servios, onde uma aplicao pode utilizar servios de diferentes provedores. Usando REST, cada provedor de servios pode denir sua forma de passar os parmetros e o formato de dados da mensagem de retorno, assim a aplicao que integra com todos os provedores precisar implementar diversos formatos de entrada e sada de dados. Com o SOAP isto no ocorre, pois todos os provedores seguem um padro bem denido e a aplicao cliente implementa apenas tal padro.

2.3.5

Arquitetura Orientada a Servios

Segundo [Sommerville 2011], uma arquitetura orientada a servios (Service Oriented Architecture - SOA) uma forma de desenvolvimento de sistemas distribudos onde os componentes de tal sistema so servios stand-alone (autnomos), executando em computadores geogracamente distribudos. Em tal arquitetura, ainda segundo [Sommerville 2011], usar Web Services uma forma de as organizaes tornarem suas informaes acessveis. Com isto, possvel haver a integrao entre empresas, mesmo que por meio de sistemas heterognos completamente diferentes.

26

Captulo 3 Arquitetura de comrcio eletrnico para a TV Digital

Neste captulo apresentada uma arquitetura para provimento de comrcio eletrnico para o Sistema Brasileiro de TV Digital. A mesma uma arquitetura distribuda, baseada em componentes reutilizveis, os Web Services, conhecida como Arquitetura Orientada a Servios. Desta forma, a arquitetura proposta foi denida, incluindo a implementao de um framework de comunicao (baseado nos protocolos HTTP e SOAP) que apresentado sucintamente neste captulo, e em mais detalhes no Captulo 5.

3.1

Requisitos da Arquitetura

A arquitetura dever atender aos requisitos apresentados na Tabela 3.1 a seguir.

27

Requisito T-01) Estar preparada para adaptao em qualquer equipamento com qualquer implementao do middleware Ginga, seja para dispositivos xos (como conversores digitais e TVs com conversores integrados), mveis (como Notebooks) ou portteis (como telefones celulares). T-02) Utilizar, preferencialmente, servios gratuitos da Web. T-03) Facilitar o desenvolvimento de aplicaes interativas para o SBTVD, inclusive com relao ao tratamento de recursos de interface grca. T-04) Tornar transparente para a aplicao de TVD os provedores de servios utilizados, permitindo a substituio por outros apenas estendendo-se classes na aplicao cliente e implementando a comunicao SOAP/HTTP com os provedores desejados. T-05) Facilitar a extenso e a manuteno das aplicaes com uso de orientao a objetos e padres de projetos. T-06) Fazer interoperao com servios de forma amigvel a rewalls. T-07) Integrar diferentes servios para compor as funcionalidades a serem disponibilizadas aos usurios das aplicaes de TVDi. T-08) Ser compatvel com padres W3C e ABNT (GingaNCL)

Funcional

No funcional x

x x

x x x

Tabela 3.1: Requisitos da Arquitetura de T-Commerce

3.2

Apresentao Geral

A arquitetura proposta baseada no conceito de Service Oriented Architecture (SOA), ou Arquitetura Orientada a Servios, onde a aplicao construda de forma distribuda, utilizando diferentes Web Services, podendo haver diferentes provedores de servios, que o caso da proposta implementada. Uma arquitetura de comrcio eletrnico considera, comumente, o conceito de loja virtual, que precisa integrar diferentes servios para prover as funcionalidades necessrias aos usurios e ao gerenciamento da mesma. Em uma aplicao de T-Commerce no diferente, o que muda apenas a plataforma, tendo-se uma interface grca de usurio especca para a TV Digital, considerando-se todas as questes de usabilidade como uso de fontes maiores

28

devido ao usurio car afastado do aparelho de TV e de integrao Web-TV referentes a esta plataforma. Todos os servios que a loja virtual j disponibiliza precisam ser acessados pela interface de TV Digital. Desta forma, a arquitetura orientada a servios vem ao encontro dessa necessidade, permitindo a integrao de uma aplicao cliente em uma plataforma diferente, possuindo uma interface grca para TV Digital, com os servios j implementados pela loja. SOA permite a integrao de sistemas hetererogneos por utilizar a tecnologia de Web Services SOAP que, diferentemente do modelo REST, dene um contrato nico que todos os provedores e consumidores de servios devem seguir (o protocolo SOAP), o que facilita a integrao de tais sistemas. Assim, para atender aos requisitos citados, a Figura 3.1 apresenta a arquitetura proposta. Cada item da mesma apresentado nas subsees a seguir, em que se adotam as seguintes convenes: as letras representam os elementos de hardware ou provedores de servio, e os nmeros representam os elementos de software (apenas os softwares aplicativos so apresentados em tal gura). Adicionalmente, embora no constando da Figura 3.1 (para dar uma viso mais simples inicialmente), os seguintes softwares so empregados (os quais so apresentados nos captulos seguintes): Framework LuaOnTV 2.0; e Framework de Comunicao de Dados.

29

Figura 3.1: Viso 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 sero executadas as aplicaes de TV Digital Interativa. Tais aplicaes so conhecidas como Thin Client (Clientes Leves/Magros)[Sommerville 2011] por apenas conterem uma camada de apresentao, todas (ou grande parte) das regras de negcio so processadas no lado servidor. Visando experimentos futuros, considera-se o uso de notebooks ou telefones celulares com implementaes de Ginga-NCL para teste das aplicaes desenvolvidas. Tais equipamentos sero 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 sero utilizadas pela aplicao de TV Digital para prover comrcio eletrnico pela TV. Tais Web Services encapsulam todas as regras de negcio para o gerencimento da loja virtual, como rotinas de cadastro de clientes, produtos, pedidos, etc. A aplicao de TV Digital consumir tal Web Service para prover muitas das funcionalidades disponveis aos usurios. O uso de tais Web Services essencial para centralizar as regras de negcio utilizadas tanto pela aplicao de E-Commerce (normalmente acessada a partir de computadores ou dispositivos mveis como aparelhos celulares) como pela aplicao de T-Commerce (acessada a partir de receptores de TVD).

C) SMS Gateway O Gateway SMS utilizado como intermedirio para comunicao via SMS da loja com o cliente. Devido arquitetura proposta ser baseada em Web Services, o uso do Gateway facilita tal integrao com a rede de telefonia celular. Um servio implementado na aplicao de T-Commerce que requer o uso de SMS a recuperao de senha, permitindo que o usurio que esqueceu a senha, receba a mesma via mensagem SMS no telefone celular que estiver cadastrado na loja. Tais servios no so gratuitos e cobram por cada SMS enviado. O uso do Gateway SMS essencial por tornar transparente para a aplicao qual a operadora sendo utilizada para enviar as mensagens SMS. Um das formas de envio de SMS utilizando softwares especcos para determinados aparelhos celulares. No entanto, para automatizar tal processo seria necessrio fazer a integrao com tal software por meio de

30

alguma API, normalmente especca do software. O uso do Gateway dispensa tal complexidade.

D) WS Preo e Prazo Sedex Na arquitetura proposta, considerou-se que as entregas da loja sejam feitas pela Empresa Brasileira de Correios e Telgrafos (ECT), denominada daqui em diante simplesmente como Correios. Desta forma, a obteno de preos, prazos de rastreamento das encomendas utiliza recursos dos Correios. Desta forma, o uso de um Web Service dos Correios facilita a obteno de tais dados a partir de qualquer aplicao.

E) WS Rastreador de Encomendas Aps o cliente ter decidido realizar a compra e naliz-la, apesar de j saber previamente qual a previso para a entrega do produto, um recurso muito utilizado o rastreamento online da encomenda. Para tal funcionalidade, pelo fato de estarem sendo usados os servios 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 endereo a partir de um Cdigo de Endereamento Postal (CEP) um requisito fundamental para a aplicao de TVD, devido ao fato de o usurio 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 aplicao de T-Commerce precisa reduzir ao mximo a quantidade de dados que o usurio deve digitar, para agilizar tal processo tedioso de entrada de dados. Na arquitetura proposta foi utilizado um Web Service para prover tal funcionalidade.

G) Servidor SMTP Como a aplicao de T-Commerce possui recurso de recuperao de senha tambm por e-mail, a arquitetura proposta inclui um servidor de Simple Mail Transfer Protocol (SMTP). Tal servidor tambm conhecido como Mail Transfer Agent (MTA), que responsvel por transferir mensagens de correio eletrnico entre um computador e outro. Por meio de tal servidor, a aplicao de TVD pode, por exemplo enviar a senha do usurio para seu e-mail ou conrmar a realizao de uma compra.

31

H) SMS Server Os Gateways SMS fazem a integrao com o SMS Server de alguma(s) operadora(s) para permitir o envio das mensagens SMS. Logo, o SMS Server o responsvel direto pelo envio das mensagens SMS pela rede de telefonia celular. Desta forma, o Gateway apenas se encarrega de fazer a integrao com o(s) servidor(es) de SMS, tornando tranparente para a aplicao esta comunicao com o terminal celular do usurio.

3.2.1

Casos de Uso das Funcionalidades da Arquitetura

Para dar uma viso geral das funcionalidades providas pela arquitetura, tanto para os desenvolvedores de aplicaes de TV Digital Interativa (TVDi), quanto para os usurios nais, so apresentados os diagramas de casos de uso a seguir.

Figura 3.2: Diagrama de Casos de Uso das Funcionalidades providas a desenvolvedores de aplicaes TVDi A Figura 3.2 apresenta as funcionalidades que a arquitetura prov aos desenvolvedores de aplicaes de TVDi, por meio dos frameworks utilizados. Tais funcionalidades permitem um grande aumento de produtividade no desenvolvimento de tais aplicaes, reduzindo a quantidade de cdigo que os desenvolvedores precisam escrever e, consequentemente, o total de bugs1 .
1

Erro no funcionamento de um software

32

Figura 3.3: Diagrama de Casos de Uso das Funcionalidades providas aos usurios das aplicaes de TVDi desenvolvidas A Figura 3.3 apresenta as funcionalidades que a arquitetura prov aos usurios de aplicaes de TVDi. As funcionalidades implementadas so as consideradas mais comuns em sistemas de E-Commerce tradicionais.

3.2.2

Tecnologias Core da Arquitetura Proposta

Em [Chu et al. 2007] so tratadas as tecnologias core para o provimento de comrcio eletrnico, divididas em quatro camadas: comunicao, apresentao e representao de informaes, linguagens, e armazenamento e recuperao de dados. A camada de comunicao conta com as tecnologias necessrias para estabelecer a comunicao entre as partes envolvidas nos sistemas de comrcio eletrnico, assim como os protocolos utilizados para garantir a interoperabilidade entre as aplicaes que compem 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 apresentao e representao de informaes contm as tecnologias que denem o formato das informaes, utilizado tanto para apresentao como para garantir a troca de informaes entre sistemas heterognos. 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 programao so utilizadas para a construo das regras de negcio das aplicaes, denindo toda a lgica das rotinas a serem executadas por elas. So utilizadas as linguagens Java, Nested Context Language (NCL) e Lua. A camada de armazenamento e recuperao de dados responsvel pelo armazenamento local ou remoto dos dados das aplicaes, como Sistemas Gerenciadores de Bancos de Dados (SGBDs). So 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

Descrio dos Componentes de Software da Arquitetura

Conforme a Figura 3.1 exibida anteriormente, nesta seo so apresentados os softwares aplicativos que compem a arquitetura.

A) Set-top Box
A.1) Aplicao de T-Commerce A aplicao a interface grca pela qual o usurio pode realizar compras por meio da TV Digital. Os requisitos funcionais da aplicao foram baseados em avaliao emprica das funcionalidades existentes na maioria dos sistemas de E-Commerce disponveis no Brasil e amplamente conhecidos e utilizados. A Tabela 3.2 apresenta os requisitos funcionais e no funcionais atendidas pela aplicao.

34

Requisito A.1-01) Permitir a exibio de produtos em destaque ao iniciar a aplicao A.1-02) Realizar a busca de produtos pelo ttulo parcial A.1-03) Adicionar produtos ao carrinho de compras A.1-04) Remover produtos do carrinho de compras A.1-05) Cadastrar vrios endereos, permitindo ao usurio escolher um endereo de entrega a partir da lista de endereos cadastrados A.1-06) Permitir mltiplas formas de pagamento, possibilitando ao usurio selecionar uma das formas suportadas A.1-07) Cadastrar usurio A.1-08) Realizar login de usurio utilizando e-mail ou CPF A.1-09) Buscar endereo a partir do CEP A.1-10) Recuperar senha por e-mail e SMS A.1-11) Rastrear automatizadamente encomendas postadas pelos Correios, exibindo ao usurio informaes sempre que a situao da encomenda mudar A.1-12) Exibir preo e prazo de entrega, baseado em Web Services dos Correios A.1-13) Realizar processo de compra em etapas, permitindo que o usurio volte a uma etapa anterior, antes de nalizar a compra, para alterar algum dado (como mudar a forma de pagamento) A.1-14) Utilizar botes coloridos do controle remoto para o acionamento da maioria das funes da aplicao A.1-15) Processar grande parte das regras de negcio nos servidores Web que integram a arquitetura, desonerando o conversor digital da maior parte da carga de processamento, considerando que o mesmo um dispositivo de recursos restritos A.1-16) Armazenar dos dados do carrinho de compras em memria RAM at a nalizao da compra, quando estes dados so enviados ao Web Service para registro da mesma A.1-17) Carregar dinmicamente a lista de produtos a partir do Web Service A.1-18) Permitir a exibio de comunicados, ofertas de produtos e promoes

Funcional X X X X X X X X X X X X X X

No Funcional

X X X

Tabela 3.2: Requisitos funcionais e no funcionais da aplicao de T-Commerce A aplicao apenas um cliente que consome os Web Services utilizados na arquitetura. Assim, a maior parte da carga de processamento e regras de negcio feita nos servidores Web que hospedam os servios. Quase todas as telas da aplicao (que podemos chamar tambm de formulrios ou pginas) fazem acesso a algum Web Service para obteno ou registro de dados. Desta forma, a aplicao totalmente dependente de um canal de interatividade (tambm conhecido como canal de retorno) para conexo Internet e acesso aos servidores Web que hospedam os servios. Como o telespectador pode visualizar e comprar qualquer produto existente na loja, e no somente aqueles que estejam em destaque, para a exibio dos produtos sempre feita uma consulta ao Web Service de E-Commerce da loja. Em outros modelos de aplicao, como o apresentado em [Sntese 2010], que exibem apenas os produtos em destaque, o telespectador no precisa ter a TV conectada Internet, pois ele s visualiza os produtos enviados pela emissora, e no pode nalizar o processo de compra pela TV. Desta forma, no h necessidade de conexo com a Internet. A arquitetura proposta vai alm deste modelo, permitindo que o usurio possa comprar qualquer produto e nalizar a compra direto da TV, o que exige a existncia de um canal de interatividade. A interface grca da aplicao foi desenvolvida utilizando-se uma nova verso do framework LuaOnTV[Jnior e Gondim 2009], cujas melhorias foram desenvolvidas no presente trabalho de dissertao e so apresentadas em detalhes no Captulo 4. O LuaOnTV a primeira e, at o momento em que esta dissertao foi desenvolvida, a nica biblioteca de

35

componentes NCLua para criao de interfaces grcas em aplicaes de TV Digital para o Ginga-NCL que se tem conhecimento. Um screenshot2 da aplicao apresentado na Figura 3.5. Tal gura mostra a tela inicial da aplicao, com os produtos em destaque na loja virtual (denidos no banco de dados da loja). O usurio pode localizar um produto a partir de uma palavra contida no ttulo, inserindo tal valor por meio do controle remoto. O apndice no nal da dissertao mostra screenshots de todas as telas da aplicao.

Figura 3.5: Aplicao de T-Commerce: Tela inicial mostrando os produtos em destaque Toda a comunicao com os servios que compem a arquitetura feita por meio do protocolo SOAP, utilizando-se a implementao de SOAP para o Ginga-NCL denominada NCLua SOAP, construda neste trabalho de dissertao e apresentada em detalhes no Captulo 5. O processo de compra na aplicao de T-Commerce desenvolvida bastante simples e direto. O diagrama de sequncia apresentado na Figura 3.6 mostra como tal processo ocorre.

Imagem capturada de uma tela de determinada aplicao em execuo

36

Figura 3.6: Aplicao de T-Commerce: Diagrama de sequncia 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 middleware Ginga) armazena a aplicao de T-Commerce alm de um leitor de RSS desenvolvidos com as linguagens NCL e Lua. Um arquivo RSS possui um formato XML e utilizado para divulgao de notcias na Internet, permitindo aos usurios assinarem os chamados feeds RSS para obterem as notcias de um determinado provedor desejado. Os feeds so os arquivos RSS que contm as notcias em formato XML. Com o RSS, a notcia vai at o usurio, no lugar de ele ir at a notcia. Assim, tendo um leitor de RSS, o usurio pode adicionar vrios feeds e receber vrias notcias de diferentes provedores. O leitor de RSS implementado para a TV Digital nesta dissertao denominado NCLua

37

RSS Reader3 . Ele implementa o padro RSS 2.0[Board 2009] e compe a arquitetura de T-Commerce para permitir que, quando o usurio no estiver acessando a aplicao da loja virtual pela TV, ele possa car atualizado com as promoes que a loja esteja divulgando. A aplicao utiliza o mdulo LuaXML4 (que foi estendido para funcionar com Lua 5). Este um parser XML escrito completamente em Lua, que permite obter as notcias do feed RSS e exibir em um equipamento de TVD. A aplicao utiliza o mdulo NCLua HTTP para fazer o download do arquivo RSS diretamente do site do provedor de contedo, neste caso o servidor Web da loja virtual. O NCLua HTTP ser apresentado no Captulo 5. O NCLua RSS Reader ainda utiliza o mdulo canvas de NCLua para desenho da interface grca, alm do mdulo event para tratamento de eventos. A Figura 3.7 apresenta um screenshot da aplicao de leitura de RSS em execuo, mostrando a mesma sendo exibida sobre o vdeo principal da emissora (em um ambiente simulado, o Ginga Virtual Set-top Box).

Figura 3.7: NCLua RSS Reader - Leitor de Notcias para TV Digital

3 4

http://ncluarss.manoelcampos.com e http://labtvdi.unb.br http://lua-users.org/wiki/LuaXml

38

A.3) Rastreador de Encomendas para TVD O rastreador de encomendas para a TV Digital faz acesso a este Web Service desenvolvido para o Ginga-NCL, utilizando as linguagens NCL e Lua e o mdulo NCLua SOAP, este a ser apresentado no Captulo 5. As Figuras 3.8 e 3.9 apresentam screenshots da aplicao em execuo. Tal aplicao, juntamente com o mdulo NCLua SOAP, foi ganhadora do Concurso Latino-Americano de Contedo para TV Digital Interativa 5 , na categoria Widgets, realizado pela PUC-Rio em 2010.

Figura 3.8: Rastreamento de encomendas pela TVD: Insero do cdigo de rastreamento

5

http://clube.ncl.org.br/node/82

39

Figura 3.9: Rastreamento de encomendas pela TVD: Situao da entrega da encomenda (atualizada automaticamente a cada 5 minutos)

B) E-Commerce WS
O E-Commerce WS contm 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 aplicaes Glass Fish 2.1 para execuo dos Web Services. Tais ferramentas foram escolhidas por serem livres e multiplataforma, amplamente utilizadas no mercado para o desenvolvimento de aplicaes, e pela familiaridade com as mesmas. O servidor de aplicaes pode ser qualquer outro (como Tomcat, Jetty ou JBoss) que implemente a especicao de Servlet 2.5. Um Servlet uma classe Java server side, ou seja, que executa do lado do servidor Web, sendo capaz de responder a requisies HTTP com resposta em formato (X)HTML, XML e outros. A escolha pelo Glass Fish veio devido ao fato de ele ser a atual implementao de referncia para a plataforma Java Enterprise Edition (Java EE), que prov as tecnologias para desenvolvimento de aplicaes Web em Java. Os mtodos desenvolvidos em cada Web Service foram implementados, baseado em um levantamento de requisitos do que deve ter uma loja virtual, como j apresentado na Tabela 3.2. Utilizou-se a linguagem UML para modelar as classes e mtodos que comporiam os servios. A Figura 3.10 apresenta um diagrama de classes com os Web Services implementados e seus respectivos mtodos.

40

Figura 3.10: Diagrama de Classes dos Web Services implementados Cada Web Service agrupa funcionalidades comuns. O "Clientes", por exemplo, prov 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 mtodos a serem acessados pela aplicao de TCommerce. Os mesmos so responsveis pelo gerenciamento de todos os dados armazenados pela loja (como produtos, clientes e pedidos de compra). Eles utilizam as classes Java apresentadas na Figura 3.11 como base para seus mtodos. Tais classes so responsveis 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 no requer muitos recursos de hardware e amplamente utilizado no mercado, alm da familiaridade com o mesmo. No entanto, a arquitetura pode utilizar qualquer outro banco de dados que for desejado, pois o acesso aos dados feito por meio da API Java Database Connectivity (JDBC) que compatvel com diversos SGBDs existentes no mercado. Alm disto, foi utilizado o padro de projeto Data Access Objects (DAO) que permite fazer uma separao total entre as classes de negcio e as instrues SQL para acesso ao banco de dados.

41

Figura 3.11: Diagrama das classes utilizadas internamente pelos WSs implementados Os Web Services no utilizam nenhum framework de persistncia por falta de familiaridade com tais tecnologias e restries de tempo. No entanto, a utilizao de algum framework como Hibernate ou Java Persistent API (JPA) no altera em nada a comunicao entre a aplicao de TVD e os Web Services. Tal mudana arquitetural pode ser feita para

42

aumentar o nvel de abstrao do acesso ao banco de dados e automatizar a gerao das instrues SQL necessrias para isto, sob pena de aumentar o overhead de acesso aos dados.

C) SMS Gateway
Para a arquitetura proposta, foi utilizado o Gateway MyTalk6 , que permite o acesso via Web Services SOAP. Contudo, tal componente pode ser substitudo na arquitetura por qualquer outro Gateway SMS. Todos os gateways encontrados e testados, disponibilizam acesso via SOAP ou REST. A escolha de tal servio foi feita por ter sido o primeiro encontrado, mas reitera-se que qualquer outro pode ser utilizado, levando-se em considerao custo, resilincia, QoS (como tempo de resposta), etc. Caso o usurio esquea sua senha, ele pode informar seu e-mail ou CPF na aplicao de TVD e recuper-la via e-mail ou SMS. Como ele normalmente estar na frente da TV, sair deste local para ir at um computador e entrar no seu e-mail para pegar uma nova senha bastante incmodo. Como o celular algo pessoal e que geralmente as pessoas o mantm por perto o tempo todo, o usurio pode receber a nova senha sem precisar sair da frente da TV, facilitando o processo de compra. Neste caso, optou-se por a aplicao de TV enviar a requisio diretamente ao Gateway SMS, no lugar de requisitar ao Web Service da loja (E-Commerce WS) para depois este despachar a requisio ao Gateway SMS, no intuito de reduzir o tempo de resposta para a aplicao de T-Commerce. No entanto, esta abordagem tem a desvantagem de vincular a aplicao a um determinado Gateway SMS. Caso escolha-se utilizar um Gateway diferente, a aplicao precisar ser atualizada. Centralizando tal regra de negcio no Web Service da loja, no haver tal problema, mas aumentar o tempo de resposta da requisio que precisar ser encaminhada ao Gateway.

D) WS Preo e Prazo Sedex

Um dos recursos bsicos que toda loja virtual deve prover a seus usurios informar o preo e prazo para entrega do produto. Tals informaes podem ser decisivas para a concretizao ou no da compra. Os Correios so responsveis por grande parte das entregas de produtos e correspondncias em todo o pas. Desta forma, a arquitetura de T-Commerce proposta faz integrao com o Web Service dos Correios7 que permite calcular o preo e prazo de entrega de uma correspondncia/produto de/para qualquer lugar do pas. Logo, a aplicao de T-Commerce consegue exibir o preo e prazo para entrega do(s) produto(s) que o usurio deseja comprar, acessando tal Web Service.
6 7

http://www.mytalk.com.br http://www.correios.com.br/webservices/

43

A atual verso da proposta permite apenas calcular preo e prazo de entrega de encomendas utilizando o servio de entregas rpidas dos Correios, denominado Sedex, mas a obteno de informaes de entrega para outros servios dos Correios pode ser feita facilmente a partir da implementao atual. A Figura 3.12 apresenta quais informaes podem ser obtidas do Web Service dos Correios.

Figura 3.12: Web Service dos Correios: Calculando preo e prazo de entrega de encomenda (fonte: http://www.correios.com.br/webservices/). O acesso ao servio feito a partir do E-Commerce WS apresentado na Seo 3.2. Assim, a aplicao de T-Commerce em NCLua envia uma requisio ao Web Service "Compras"que possui o mtodo "calcularSedex"que retorna as informaes sobre preo e prazo de entrega, como apresentado no diagrama de classes da Figura 3.10.

E) WS Rastreador de Encomendas
Os Correios possuem um servio na Internet que permite ao usurio saber a situao da entrega de uma determinada encomenda, a partir do cdigo de rastreamento da mesma. No entanto, o usurio, para car atualizado da situao, precisa periodicamente acessar tal pgina, gastando tempo que ele poderia utilizar em outras atividades mais importantes.

44

Assim, na arquitetura proposta, decidiu-se implementar um servio automatizado para rastreamento de encomendas, onde o usurio possa acessar o servio e deixar a tela do mesmo aberta, sem precisar interagir com ela ou car voltando l para vericar se a situao da encomenda mudou. Uma vez tendo aberta a tela do servio, o usurio ser automaticamente noticado por meio de uma mensagem sonora, que a situao da encomenda mudou. O servio est disponvel via Web8 e foi tambm implementado em uma aplicao de TV Digital para o Ginga-NCL. Como os Correios no disponibilizam tal servio de rastreamento por meio de um Web Service, para facilitar a integrao do servio em diferentes arquiteturas, foi desenvolvido um Web Service para o rastreador. Este responsvel por fazer o parse do cdigo HTML da pgina do servio dos Correios e obter as informaes sobre o rastreamento da encomenda. Tais informaes so extradas e retornadas pelo Web Service de forma estruturada, permitindo a exibio delas facilmente em qualquer aplicao em diferentes plataformas. Um exemplo a aplicao iComenda9 , desenvolvida por Maurcio Jnior10 , para os dispositivos mveis iPhone, iPod e iPad, a partir do Web Service disponibilizado.

F) WS Busca CEP
Infelizmente os Correios no disponibilizam um Web Service para a consulta de endereos a partir de um nmero de CEP. S h disponvel uma pgina Web para usurios nais11 que retorna os dados do endereo como uma imagem, para impedir (ou pelo menos dicultar bastante) que aplicaes consigam acessar a pgina e extrair tais dados. Tal atitude provavelmente devida ao fato de os Correios terem um software comercial, denominado Guia Postal Brasileiro Eletrnico12 , contendo um banco de dados de CEPs, que vendido na sua loja virtual e nas agncias. No entanto, existem alguns Web Services de terceiros que permitem obter o endereo a partir de um CEP. Qualquer um deste servios pode ser utilizado na arquitetura implementada para permitir a obteno de endereos. Para a implementao 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 servio requer a realizao de um cadastro prvio para poder acess-lo, e com os poucos testes realizados, retornou os endereos corretos e atualizados. A aplicao de T-Commerce faz acesso direto a tal servio para obter um endereo, utilizando-se o mdulo NCLua SOAP.
http://rastreador.manoelcampos.com e http://labtvdi.unb.br 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
9 8

45

G) Servidor SMTP
Para envio de e-mail, a aplicao de T-Commerce acessa o mtodo sendMail do Web Service "Clientes"do E-Commerce WS, apresentado na Seo 3.2 e na Figura 3.10, para enviar e-mail ao cliente. Desta forma, a aplicao cliente no acessa diretamente o servidor de e-mail. O E-Commerce WS que faz esta integrao, despachando a requisio 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 aplicao, o servidor de e-mail utilizado e as conguraes para acesso ao mesmo. Na implementao feita, foi utilizado um servidor de e-mail disponibilizado por um plano de hospedagem prossional, logo um servio com custo mensal. No entanto, pode-se utilizar qualquer servidor de e-mail que desejar, como por exemplo um que seja disponibilizado por servios de WebMail gratuitos, amplamente difundidos na Internet e usados no cotidiano.

3.4

Diagrama de Distribuio/Implantao

A Figura 3.13 apresenta um diagrama de distribuio/implantao que mostra como os componentes da arquitetura, apresentados na Seo 3.2 so distribudos em diversos hardwares, mostrando a arquitetura distribuda montada e a relao de dependncia entre cada componente. Tal diagrama apresenta todos os componentes de hardware e software da arquitetura proposta, incluindo os softwares aplicativos e os frameworks implementados.

Figura 3.13: Arquitetura de T-Commerce: Diagrama de Distribuio/Implantao

46

As funcionalidades de cada componente so resumidas a seguir: A) Set-top Box - Conversor de TV Digital, TV com conversor integrado, notebook ou celular que executa as aplicaes de TVD desenvolvidas: 1 - Aplicao T-Commerce: aplicao de comrcio eletrnico para TVD (aplicao 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 usurio rastrear a entrega do(s) produto(s) comprado(s) por meio da TV Digital, sendo noticado sempre que a situao da encomenda mudar; 4 - NCLua SOAP: mdulo para acesso a Web Services SOAP em aplicaes NCLua para TVD; 5 - NCLua HTTP: mdulo que implementa o protocolo HTTP, utilizado pelo NCLua SOAP e por aplicaes como o NCLua RSS Reader. O mdulo apresentado no Captulo 5; 6 - LuaOnTV 2.0: framework para construo da interface grca da aplicao de T-Commerce. B) E-Commerce Host - Servidor Web que hospeda os Web Services a serem utilizados pela aplicao de T-Commerce: 7 - ECommerceWS: Web Services da loja virtual, implementados em Java com a API JAX-WS; 8 - DB Connection Pool: pool de conexes ao banco de dados, implementado utilizando a API JDBC, que permite que conexes ao banco de dados sejam compartilhadas entre diferentes requisio 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 divulgados 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 servio MyTalk SMS, um Gateway para envio de mensagens SMS. D) Correios Host - Host dos correios que hospeda Web Services como os para consulta de preo e prazo de entrega de encomendas:

47

 12 - ws.correios.com.br: Web Services dos Correios para consulta de preo e prazo de entrega de encomendas. E) Rastreador Host - Host que armazena o servio 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 servios de busca de endereo a partir do CEP: 14 - CEP WS: Web Service maniezo.com.br que fornece o endereo 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 eletrnicas aos clientes da loja virtual. H) SMS Server - Host de uma operadora de telefonia celular, responsvel pela comunicao via SMS com o terminal celular do usurio.

3.5

Ambiente de desenvolvimento

Para o desenvolvimento do projeto foram utilizados: sistema operacional GNU/Linux Ubuntu 10.10 como sistema desktop para realizao 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 aplicao Ginga-NCL: plugin NCLEclipse 1.5.1; plugin LuaEclipse 1.3.1; ferramenta LuaDoc13 para gerao de documentao; implementao de referncia do Ginga-NCL (Ginga Virtual Set-top Box 0.11.2); interpretador Lua para execuo do scripts fora do Ginga Virtual Set-top Box; XVidCap 1.1.7 para captura de screencasts14 da aplicao em execuo;
13 14

http://luadoc.luaforge.net Vdeo mostrando a execuo de determinada aplicao

48

 IDE NetBeans 6.7.1 para modelagem UML e desenvolvimento dos Web Services da loja virtual, utilizando API JAX-WS; servidor de aplicaes Glass Fish 2.1 para execuo 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 aplicaes; Java Runtime Environment (JRE) 1.6.0.24, o ambiente de execuo Java para execuo das aplicaes Java como os Web Services criados, os IDEs e outras ferramentas desenvolvidas 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 administrao do banco de dados; PHP 5.3 e Apache 2 para execuo do PhpMyAdmin; VirtualBox 4.0 e RemasterSys para criao de distribuio Linux contendo todo o ambiente de desenvolvimento, com todas as ferramentas apresentadas acima.

3.6

Distribuio GNU/Linux para desenvolvimento, execuo e teste de aplicaes de TV Digital

Com base no trabalho apresentado em [Monteiro et al. 2010], foi gerada uma distribuio GNU/Linux contendo todo o ambiente de desenvolvimento necessrio para a construo das aplicaes apresentadas ao longo deste trabalho. O ambiente contm todas as ferramentas apresentadas em 3.5. Tal distribuio GNU/Linux foi elaborada com o intuito de facilitar a montagem do ambiente de desenvolvimento necessrio para a construo de aplicaes NCL/Lua para a TV Digital. A comunidade Ginga no Portal do Software Pblico disponibiliza uma implementao de referncia do sub-sistema Ginga-NCL em forma de uma mquina virtual j com tal implementao compilada e instalada. Tal mquina virtual facilita bastante a montagem do ambiente de desenvolvimento, uma vez que o processo de compilao de tal implementao bastante extenso, dependendo de diversos softwares e bibliotecas, no sendo um processo trivial de ser executado, principalmente para usurios menos experientes com distribuies GNU/Linux e ferramentas de compilao de linha de comando. No entanto, o uso de uma mquina virtual adiciona um overhead de tempo no processo de teste das aplicaes, uma vez que os arquivos das mesmas precisam ser enviados via SSH para a mquina virtual, apesar de tal processo ser automatizado com o plugin NCL Eclipse.
15

http://java.net/projects/openesb

49

Desta forma, a instalao da implementao de referncia do Ginga-NCL diretamente no sistema operacional utilizado pelo desenvolvedor para as suas tarefas rotineiras (como envio de e-mails, elaborao de documentos em suites de escritrios, etc) e de desenvolvimento de sistemas agiliza bastante o processo de execuo e teste das aplicaes interativas, pois, como o Ginga instalado localmente na mquina real, no h processo de transferncia de arquivos para poder executar as aplicaes. Com isto, a execuo das aplicaes praticamente instantnea, alm de obter-se melhor desempenho executando o Ginga nativamente no sistema operacional da mquina real, uma vez que o uso de uma mquina virtual obviamente requer o consumo de mais memria RAM e processador que executar o Ginga nativamente em uma mquina real. A distribuio desenvolvida foi baseada na verso 10.10 do Ubuntu e permite o uso do ambiente de desenvolvimento sem a necessidade de instalao do mesmo na mquina do desenvolvedor, podendo ser dado boot na mquina por meio de um CD contendo tal distribuio, conhecido como Live CD. Ela pode ser instalada em uma mquina real, onde o usurio poder utilizar tal distribuio como seu sistema operacional Desktop para a realizao de suas tarefas rotineiras e de desenvolvimento e ainda pode ser instalada em uma mquina virtual, j com o ambiente grco e todas as ferramentas de desenvolvimento necessrias. A verso da implementao de referncia do Ginga-NCL embarcada na distribuio a ltima (at a data de entrega de tal dissertao), a 0.11.2 reviso 23, disponvel na Comunidade Ginga do Portal do Software Pblico16 . O processo de criao da distribuio GNU/Linux consistiu basicamente em: instalar distribuio Ubuntu 10.10 em uma mquina virtual utilizando a ferramenta Virtual Box 4.0; baixar e compilar a implementao de referncia do Ginga-NCL em tal mquina virtual, juntamente com todas suas dependncais; instalar ferramentas de desenvolvimento e suas dependncias (como JDK e JRE); congurar ferramentas de desenvolvimento para permitir a execuo local de aplicaes NCL/Lua; gerar uma nova distribuio a partir do ambiente criado, j com todas as ferramentas instaladas, utilizando o software RemasterSys17 . Tal distribuio pode ser obtida pelo site do Laboratrio de TV Digital Interativa da Universidade de Braslia18 .
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 aplicaes interativas"apresentado na Seo 3.1, foi utilizado o framework LuaOnTV, como ponto de partida, no qual foram realizadas melhorias a serem apresentadas neste captulo. O LuaOnTV[Jnior e Gondim 2009] um framework para facilitar o desenvolvimento de aplicaes 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 Laboratrio de TV Digital Interativa da Universidade de Braslia, sob orientao do professor Paulo Roberto de Lira Gondim. Ele foi um projeto pioneiro para o SBTVD, desenvolvido inteiramente em linguagem Lua, sob o paradigma de programao orientada a objetos, que disponibiliza um conjunto de classes e componentes visuais e no visuais para o desenvolvimento de aplicaes interativas para TVD. Os componentes do LuaOnTV utilizam os mdulos canvas e event existentes em NCLua. Tais mdulos estendem as funcionalidades da linguagem Lua para o contexto de TV Digital. Desta forma, o framework est totalmente em conformidade com as normas do Ginga-NCL. O framework tem como principal objetivo facilitar a construo de interfaces grcas para aplicaes interativas, disponibilizando componentes para entrada e sada de dados, alm de automatizar o processo de controle de foco. Os componentes visuais foram desenvolvidos com base nos componentes existentes em diferentes linguagens de programao e ambientes integrados de desenvolvimento (IDEs) como NetBeans, Eclipse, Adobe Dreamweaver, Delphi, Visual Studio e outros; alm de ferramentas especcas para TV Digital como Jame Author e Cardinal Studio. [Jnior e Gondim 2009] compararam uma aplicao desenvolvida utilizando a NCL como linguagem principal e outra utilizando o LuaOnTV, que tem a linguagem Lua como principal, e constataram que: "uma aplicao com cdigos NCL e imagens que simulam os componentes grcos do LuaOnTV chegou a quase 1,5MB. A mesma aplicao desenvolvida

51

com LuaOnTV chegou a pouco mais de 60 KB." Eles tambm comentam que o framework tem como um dos requisitos no funcionais a diminuio do tamanho do cdigo das aplicaes interativas, considerando as capacidades restritas de memria e armazenamento dos conversores de TV Digital. Tal requisito foi alcanado devido utilizao do paradigma de orientao a objetos, que permite uma alta reutilizao de cdigo.

4.1

Delimitao do Problema

Devido 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, no restringindo nem prescrevendo nenhum tipo de mdia)[ABNT 2008], ela uma linguagem de maior nvel de abstrao, no decompondo o resultado em uma implementaco algortmica[Barbosa e Soares 2008]. No entanto, tal linguagem no permite realizao de tarefas especcas como operaes aritmticas, utilizao direta de protocolos de comunicao como TCP, HTTP e SOAP, manipulao de arquivos, muito menos a denio de procedimentos (rotinas/funes). Desta forma, a realizao de tais tarefas s 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 aplicaes NCL[ABNT 2008], a implementao de referncia do mesmo[PUC-Rio 2010] ainda no inclui tal recurso. Alm disto, a manipulao de dados (armazenamento e obteno) em documentos NCL no to trivial como a incluso de mdias como imagens e vdeos. Em NCL possvel at mesmo denir o controle de foco entre campos (por meio dos atributos moveLeft, moveRight, moveUp, moveDown, da tag descriptor[ABNT 2008]) permitindo que o usurio navegue de um campo a outro utilizando as setas do controle remoto. No entanto, a denio da navegao entre os campos feita de forma completamente manual, e a incluso ou remoo de um novo campo no meio dos campos existentes requer a redenio da ordem de navegao entre os mesmos, o que pode ser um trabalho cansativo e suscetvel a erros. Os mdulos de NCLua, utilizados pelo LuaOnTV, disponibilizam apenas um conjunto de funes bsicas especcas. Existem 5 mdulos, como apresentados a seguir[ABNT 2008]: canvas: oferece uma API para desenhar primitivas grcas e manipular imagens; event: permite que aplicaes NCLua comuniquem-se com o middleware atravs de eventos (eventos NCL e de teclas); settings: exporta uma tabela com variveis denidas pelo autor do documento NCL e variveis de ambiente reservadas em um n "application/x-ginga-settings";

52

 persistent: exporta uma tabela com variveis persistentes, que esto disponveis para manipulao apenas por objetos procedurais. A utilizao direta das funes destes mdulos requer um conhecimento mais profundo dos mesmos, como temos provado durante a pesquisa e estudos de tais mdulos, para o desenvolvimento de aplicaes. As funcionalidades de captura de teclas (providas pelo mdulo event) para entrada de dados alfabticos e numricos, da mesma forma como em um teclado de celular (devido o controle remoto s possuir teclas numricas) no trivial. O controle de foco a partir da captura do pressionamento das teclas direcionais do controle tambm complicado e requer a incluso de muito cdigo. Tais diculdades tm se provado verdade pelos diversos relatos de usurios, como no Frum da Comunidade Ginga no Portal do Software Pblico[PUC-Rio 2010], alm de outros grupos de discusso acompanhados. Com todas as diculdades apresentadas, o LuaOnTV se mostrou ser uma soluo ideal para a reduo da quantidade de cdigo para a criao de aplicaes procedurais com interface grca para a TVD, permitindo encapsular toda a complexidade envolvida na utilizao direta dos mdulos de NCLua para chegar ao mesmo m.

4.2

LuaOnTV 2.0: Nova verso implementada

Da mesma forma que todo projeto de software, foi implementada e liberada uma primeira verso do LuaOnTV. Como extenso do trabalho de mestrado onde foi originado o mesmo, vericou-se que eram necessrias algumas melhorias e correes de alguns bugs encontrados. Nesta seo ser apresentada a verso 2.0 do LuaOnTV, que traz uma srie de importantes novos recursos. A seguir so listados os requisitos funcionais e no funcionais, inicialmente identicados e implementados.
Requisito A.6-01) Correo de bugs e melhoria de desempenho na entrada de dados e desenho da interface de usurio A.6-02) Reduo da quantidade de cdigo para incluir e congurar um componente na tela A.6-03) Criao de exemplos com os novos recursos implementados A.6-04) Adaptao de interface para dispositivos portteis A.6-05) Adaptao de interface para diferentes denies de tela A.6-06) Temas para os componentes grcos A.6-07) Posicionamento e dimenses de componentes e fontes em percentual A.6-08) Centralizao da interface na tela do dispositivo em casos onde a denio da tela for maior do que a da aplicao Funcional No Funcional x x x x x x x x

Tabela 4.1: Requisitos funcionais e no funcionais implementados na nova verso do LuaOnTV

53

4.2.1

Melhoria de Desempenho

Um dos principais problemas do LuaOnTV em sua verso 1.0 estava relacionado ao desempenho. Durante a utilizao do mesmo, foi detectada uma lentido na resposta aos eventos disparados pelo usurio (como a mudana de foco e entrada de caracteres pelo controle remoto). Foi realizada uma investigao, estudando-se a arquitetura do framework, onde observou-se que a causa de tal lentido era devida ao redesenho de todos os componentes na tela, a cada boto que o usurio pressionava no controle remoto, ou a cada mudana de foco ocorrida. O mdulo canvas de NCLua, utilizado para desenhar os campos e imagens na tela, permite trabalhar com camadas, no entanto, as camadas no so totalmente independentes. Assim, quando uma camada composta sobre outra, esta passa a ser parte da segunda camada, no permitindo mais a separao 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 lentido bastante perceptvel. O problema acima descrito foi corrigido: assim, a tela s totalmente desenhada no momento em que a aplicao inicializada. A cada evento ocorrido, somente a parte afetada da tela redesenhada. Por exemplo, quando um componente no est em foco, sua borda padro de cor preta. Quando ele recebe foco, a borda alterada para vermelha. Desta forma, neste evento, implementou-se a alterao 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 alteraes realizadas pelo usurio por meio do controle remoto.

4.2.2

Temas

A criao de interfaces grcas com o LuaOnTV no permitia a denio da aparncia dos componentes de forma centralizada, a no ser alterando o cdigo nas classes do framework. Caso o desenvolvedor desejasse denir caractersticas visuais diferentes das especicadas pelo framework, uma alternativa seria denir em cada componente inserido, as caractersticas desejadas (como estilo e tamanho de fonte, cores, dimenses e posicionamento). Tal abordagem torna bastante trabalhoso o processo de mudar a aparncia atual, precisando-se denir tais caractersticas para todos os objetos instanciados. Tendo em vista tal decincia, foi implementado no framework um recurso de temas. Este recurso bastante conhecido em aplicaes de diferentes plataformas, como o caso do recurso denominado look-and-feel da biblioteca de componentes Swing da plataforma Java[Fowler 2000]. A Swing uma biblioteca bastante conhecida pelos desenvolvedores Java. Sua verso atual bastante madura e estvel e seu modelo de componentes fortemente denido em uma arquitetura orientada a objetos, seguindos padres de projetos consolidados pela academica e pela indstria 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 utilizao e amplo sucesso do Swing. Desta forma, foi implementada uma classe Theme que a classe base para implementao de qualquer tema. A partir desta classe, foram criadas as classes MasterTheme e DefaultTheme. A MasterTheme dene as caractersticas padres para todos os temas. A DefaultTheme implementa o tema padro a ser utilizado pelas aplicaes caso nenhum seja denido pelo programador. A classe ThemeManager responsvel por carregar um determinado tema para os componentes da aplicao. A classe do tema (como DefaultTheme) contm as caractersticas que sero herdadas por todos os componentes utilizando o tema. Para cada componente do LuaOnTV pode-se denir 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 componente no momento de instanci-lo ou setando propriedades especcas posteriormente, por meio dos mtodos setters1 do componente. O conjunto de classes de temas permitem que sejam criados temas para diferentes denies de tela (como Low Denition, Standard Denition, High Denition e Full High Denition), permitindo a adaptao automtica da interface da aplicao, de acordo com a resoluo 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 mesmo um celular com o middleware Ginga. Considerando que apenas o sub-sistema Ginga-NCL obrigatrio para dispositivos portteis com TV Digital Interativa (como celulares), e que o Ginga-NCL e Ginga-J devem estar presentes em todas as implementaes de Ginga para receptores xos e mveis, o desenvolvimento de aplicaes com garantia de execuo em todos os tipos de dispositivos com Ginga s possvel se desenvolvidas para o Ginga-NCL. Desta forma, o desenvolvimento de aplicaes em Ginga-J no garante que podero ser executadas tambm em dispositivos portteis. Assim, para que o desenvolvedor no tenha que implementar duas aplicaes (uma em Ginga-J para receptores xos e mveis e outra em Ginga-NCL para receptores portteis), preciso implementar a aplicao em Ginga-NCL. No entanto, mesmo em Ginga-NCL, utilizando as bibliotecas de NCLua citadas anteriormente, pode haver um grande trabalho para adaptar a interface da aplicao para diferentes dispositivos e denies de tela. O recurso de temas implementado no LuaOnTV permite que todos esses detalhes sejam abstrados pela criao de temas diferentes para dispositivos e denies de telas diferentes.
1

Mtodos responsveis por alterar o contedo de um determinado atributo de uma classe

55

Um dos recursos implementados, utilizados pelos temas, que permitem essa independncia de denio de tela foi o de informar posies, dimenses e tamanho de fonte de componentes por meio de valores percentuais. O mdulo canvas de NCLua s permite o uso de valores absolutos em suas funes. Tais funcionalidades foram estendidas pelo LuaOnTV, tendo por base os recursos das Folhas de Estilo em Cascata (Cascade Style Sheets, CSS)[W3C 2009], amplamente utilizadas em pginas HTML. Tal recurso permite a adaptao automtica da fonte e das dimenses do componente, de acordo com o tema denido, adicionando recursos de acessibilidade nas aplicaes interativas, pois o tamanho da fonte e dos componentes pode ser alterado dinamicamente. Desta forma, o desenvolvedor pode incluir os conhecidos botes "A+"e "A-"na aplicao, para dinamicamente aumentar ou diminuir o tamanho da fonte da aplicao. Alguns outros recursos implementados no LuaOnTV foram: posicionamento automtico de campos na tela: caso o desenvolvedor no informe posies (left e top) para um componente, ele ser automaticamente posicionado na tela, com base nas coordenadas do ltimo componente inserido, permitindo um ajuste automtico da interface em telas de denies diferentes; centralizao de layout automtico na tela de diferentes dispositivos: permite centralizar a interface da aplicao na tela do dispositivo, em casos de a aplicao estar executando em telas de grandes denies, o que pode fazer com que sobre espao nos quatro lados da tela; simplicao do conjunto de classes e componentes: criao de um nico componente para permitir a entrada de texto, de nmeros e de senhas. Propriedades foram adicionadas para denir o comportamento de entrada de dados no componente; simplicao do modelo de construo de aplicaes: foi reduzida a quantidade de cdigo necessria para incluir um componente na tela, implementando, por exemplo, o controle automtico de foco. Assim, a cada campo includo, ele automaticamente recebe uma numerao 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 responsvel pelo tratamento dos eventos ocorridos na aplicao, principalmente os eventos de pressionamento de teclas, controlando a entrada de dados na tela e a navegao entre os campos por meio das teclas direcionais do controle remoto. Desta forma, a Figura 4.2 apresenta um grco de mquinas estados desta classe.

Figura 4.2: Grco de Mquinas 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 mdulos 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 pacotes principais: Components, contendo as classes que implementam os componentes visuais e no visuais; e Themes, contendo as classes que implementam os temas. O LuaOnTV cria uma camada de abstrao para os mdulos canvas e event do Ginga-NCL, provendo funcionalidades de mais alto nvel.

Figura 4.4: Diagrama de Componentes do LuaOnTV

59

Captulo 5 Framework de comunicao de dados

A arquitetura apresentada no Captulo 3 utiliza protocolos de comunicao HTTP e SOAP. Tais protocolos foram implementados em um framework de comunicao a ser apresentado neste captulo.

5.1

Integrao entre Web e TV

Um dos grandes atrativos da TV Digital (TVD) com certeza a interatividade. Existem diversas categorias de aplicaes interativas como jogos, informaes (notcias, horscopo, previso do tempo, etc), educao (T-Learning), governo eletrnico (T-Government), comrcio eletrnico (T-Commerce), sade (T-Health), bancrias (TBanking) e outras, como apresentado em [Fernndez e Goldenberg 2008], [Teixeira 2006] e [Barbosa, Kutiishi e Lima 2010]. O nvel de interatividade das aplicaes vai desde a chamada interatividade local (onde os usurios/telespectadores podem acessar apenas os dados enviados pela emissora, por radiodifuso) at a interatividade plena (onde os usurios/telespectadores dispem de um canal de retorno, permitindo enviar e receber dados em uma rede como a Internet) [Soares e Barbosa 2009]. Tais aplicaes que permitem interatividade plena precisam utilizar protocolos de comunicao padres e consolidados na Internet (como TCP, HTTP e SOAP) para garantir a interoperabilidade com outros sistemas. Utilizando os protocolos citados, possvel garantir a convergncia entre Web e TV. Com isto, as aplicaes de TVDi podem ser enriquecidas com contedo proveniente da Internet, como o caso da aplicao que busca contedo na Wikipdia, baseada nas tags do programa em exibio, obtidos a partir do Guia Eletrnico de Programao (cujas informaes so 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 aplicaes. Tendo em vista o cenrio supracitado, so apresentados neste trabalho os projetos NCLua HTTP e NCLua SOAP: implementaes dos protocolos HTTP e SOAP, respectivamente, para o sub-sistema Ginga-NCL, utilizando linguagem Lua, que permitem a convergncia entre aplicaes de TVDi e a Web. A escolha de implementao de HTTP e SOAP partiu da inexistncia de verses livres e de cdigo aberto de tais protocolos para o Ginga-NCL. At onde sabe-se, o NCLua HTTP e NCLua SOAP so as primeiras implementaes livremente disponibilizadas.

5.2

Delimitao do Problema

Apesar de Lua ser uma linguagem extensvel [Ierusalimschy, Figueiredo e Celes 2007], principalmente pela capacidade de utilizar mdulos construdos em linguagem C, e de existirem vrios destes mdulos para as mais diversas nalidades, tais mdulos binrios no podem ser utilizados em aplicaes interativas de TV Digital enviadas via broadcast, devido a questes de segurana, uma vez que um mdulo 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] so citadas algumas ameaas de segurana em sistemas de TVDi, como transao fraudulenta (perda/roubo de dados), pirataria de contedo, falsicao, violao ou corrupo das aplicaes e uso ilegtimo de servios do provedor. Tais ameaas podem ser potencializadas com o uso de mdulos binrios. Alm do mais, a compilao de mdulos em C gera cdigo nativo dependente de plataforma, o que no garante que a aplicao executar em qualquer receptor [Costa 2009]. Somente aplicaes residentes podem ser desenvolvidas em linguagens compiladas como C. Com isto, para haver, em aplicaes NCLua de TVDi, algumas das funcionalidades dos mdulos binrios citados, preciso implementar mdulos inteiramente em linguagem Lua, cujo ciclo de vida controlado pelo middleware Ginga[ABNT 2008].

5.3

Tecnologias Envolvidas e Trabalhos Relacionados

Nesta seo so apresentadas as tecnologias envolvidas no desenvolvimento da soluo apresentada e os trabalhos relacionados.

61

5.3.1

Tecnologias de Web Services

SOAP um protocolo padro da World Wide Web Consortium (W3C) que permite a aplicaes oferecerem seus servios na Internet, em uma arquitetura distribuda no modelo cliente/servidor. O protocolo permite troca de mensagens e chamadas de procedimentos remotos. Tais servios podem ser providos e consumidos por aplicaes desenvolvidas em diferentes linguagens e plataformas. Isto permite a interoperabilidade entre diferentes aplicaes, 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 integrao de aplicaes a sua linguagem para descrio dos servios disponibilizados, a Web Service Description Language (WSDL). De forma padronizada, manual ou automatizadamente, uma aplicao cliente pode conhecer os servios disponibilizados por um Web Service lendo o documento WSDL do servio (tambm em formato XML)[W3C 2007]. Os Web Services permitem a construo de aplicaes distribudas pela Internet, garantindo a centralizao de regras de negcios em servidores de aplicaes, encarregados de toda a carga de processamento de tais regras. Considerando-se isto, Web Services so ideais para aplicaes clientes executando em sistemas com restritos recursos de hardware, como celulares e Set-top Boxes, estes ltimos sendo o foco do presente trabalho. Alm de desonerar os clientes da carga de processamento, alteraes nas regras de negcio no requerem a atualizao das aplicaes clientes.

5.3.2

Lua e os scripts NCLua

Lua a linguagem imperativa utilizada pelo sub-sistema Ginga-NCL para o desenvolvimento de aplicaes procedurais. Ela tem como grandes vantagens sua simplicidade, ecincia e portabilidade. Tais caractersticas so extremamente importantes em uma linguagem a ser utilizada em dispositivos com recursos de hardware restritos, como os conversores de TV Digital (Set-top Boxes). Alm de tudo, Lua livre de royalties, o que permite que a mesma seja embarcada em Set-top Boxes sem onerar o custo dos equipamentos. Este um requisito muito importante, considerando as caractersticas scio-econmicas do Brasil, a inteno do governo de utilizao da TV como meio para incluso digital e sua presena na grande maioria dos lares brasileiros. Como a linguagem NCL apenas declarativa, a incluso de caractersticas imperativas a uma aplicao de TVDi para o Ginga-NCL possibilitada por meio dos chamados NCLua, scripts Lua funcionando como ns de mdia dentro de um documento NCL [ABNT 2008] [Soares, Rodrigues e Moreno 2007]. Tais scripts aumentam o poder das aplicaes de TVDi, possibilitando a construo de aplicaes sosticadas, seguindo paradigmas como Programao Estruturada e Programao

62

Orientada a Objetos, com denio de regras de negcio na aplicao, 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 a possibilidade de comunicao bidirecional entre este e o documento NCL. Tal comunicao acontece por meio de eventos, como denido na norma do Ginga-NCL em [ABNT 2008]. Segundo [SantAnna, Cerqueira e Soares 2008] "essa integrao deve seguir critrios que no afetem os princpios da linguagem declarativa, mantendo uma separao bem denida entre os dois ambientes". Para isto, nenhuma alterao nas linguagens NCL ou Lua foi necessria, o que garante a evoluo independente das linguagens, como ressalta [SantAnna, Cerqueira e Soares 2008]. A integrao entre as linguagens NCL e Lua foi feita para ser minimamente intrusiva, garantindo uma separao entre a forma declarativa e a procedural de desenvolver uma aplicao para o Ginga-NCL. Assim, o cdigo NCLua deve ser escrito obrigatoriamente em um arquivo separado do NCL. Isto permite uma clara diviso de tarefas entre prossionais da rea de design e da rea de programao [SantAnna, Cerqueira e Soares 2008]. A integrao entre outras linguagens como HTML e JavaScript bastante intrusiva, onde, muitas vezes, cdigo JavaScript intercalado com cdigo HTML. O tratamento de eventos e as particularidades associadas a aplicaes de TVDi, desenvolvidas em linguagem Lua, so implementadas por mdulos adicionais Linguagem, denidos na norma do Ginga-NCL [ABNT 2008]. Isto permite que a linguagem se mantenha inalterada para o contexto de TV Digital. Os mdulos disponveis em NCLua, utilizados neste trabalho so: event, que permite a comunicao bidirecional entre um NCL e um NCLua; e canvas, que disponibiliza uma API para desenhar imagens e primitivas grcas.

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 aplicaes interativas. Como os objetos NCLua tm a caracterstica de poderem ser orientados a eventos, o mdulo event permite a captura e tratamento de eventos, possibilitando a comunicao assncrona entre o formatador NCL e um objeto NCLua. A implementao do protocolo TCP deve ser disponibilizada por meio do mdulo event. A norma especica uma classe de eventos denominada tcp. Assim, por meio das funes do mdulo event, um objeto NCLua pode enviar requisies e receber respostas usando o protocolo TCP. Devido caracterstica assncrona do mdulo event, o tratamento de requisies TCP em NCLua no 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 similar a um thread (no sentido de multithreading). No entanto, co-rotinas so colaborativas, sendo executada apenas uma por vez.

63

A documentao de NCLua disponvel em [SantAnna 2010], apresenta um mdulo que utiliza co-rotinas para facilitar o tratamento das requisies assncronas da classe de eventos tcp. No entanto, mesmo tal mdulo ainda no permite encapsular todos os detalhes do envio da requisio em apenas uma funo, para simplicar o uso para os desenvolvedores de aplicaes interativas. A Figura 5.1 apresenta um grco de mquinas de estados da realizao de uma conexo TCP no Ginga-NCL, utilizando o mdulo tcp.lua. Em um processo convencional, a aplicao estabelece uma conexo a um servidor. Aps estabelecida a conexo ela envia uma requisio e ca aguardando o retorno. A funo tcp.receive executada at que no haja mais dados a serem recebidos, realizando a desconexo.

Figura 5.1: Diagrama de Mquinas de Estados do Mdulo tcp.lua A Figura 5.2 apresenta um grco de mquinas de estados do mesmo mdulo, porm, do ponto de vista das co-rotinas em execuo (que so semelhantes a threads, como j discutido anteriormente). O processo de uso do mdulo iniciado internamente com a criao de uma corotina (que criada suspensa, no automaticamente iniciando sua execuo). A funo coroutine.resume inicia a execuo da co-rotina. Quando solicitada uma tentativa de conexo, a co-rotina suspensa, cando aguardando at que a conexo seja estabelecida, ocorrendo tudo de forma assncrona. Neste momento, a co-rotina novamente resumida (continuando a execuo), permitindo que seja enviada uma requisio ao servidor (tcp.send). Tal funo retorna imediatamente. Para a obteno da resposta da requisio (que tambm ser feita de forma assncrona), preciso usar a funo tcp.receive, que faz com que a co-rotina seja suspensa novamente, at que algum dado da resposta seja obtido. A funo tcp.receive pode ser chamada iterativamente at que no haja mais nenhum dado a ser retornado para a aplicao. Todo este processo apresentado nos grcos de mquinas de estado, mesmo utilizando as facilidades providas pelo mdulo tcp.lua, no so encapsulados para facilitar o uso. O mdulo citado apenas facilita o gerenciamento das chamadas assncronas. A implementao do NCLua HTTP e NCLua SOAP encapsulam todas essas chamadas de funes, tornando o processo bem mais simples para o desenvolvedor, disponibilizando uma simples funo para realizao de uma requisio. importante lembrar que tal abordagem til em cenrios de aplicaes stateless, que no mantm estado entre uma requisio e outra, como o caso do HTTP/1.0 e das chamadas SOAP. Aplicaes que precisem manter a conexo aberta, como mensageiros instantneos, precisam utilizar diretamente as funes do mdulo tcp.lua.

64

Figura 5.2: Diagrama de Mquinas de Estados do Mdulo tcp.lua (co-rotinas em execuo)

5.3.4

Implementaes de SOAP

Existem diversos toolkits para provimento e consumo de Web Services, disponveis em diferentes linguagens e plataformas. Nas sub-sees seguintes so apresentados alguns destes.

5.3.4.1

LuaSOAP

Para acesso a Web Services SOAP a partir de aplicaes Lua, pode-se utilizar o mdulo 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 entanto, para fazer o parse de arquivos XML, o LuaSOAP depende da biblioteca Expat [Jr e Waclawek 2007][Cooper 1999], que um parser XML desenvolvido em linguagem C, cujos problemas de uso em aplicaes de TVDi foram apresentados na Seo 5.2. O projeto tambm depende da biblioteca LuaSocket, que tambm usa mdulos em C. O LuaSOAP no permite a gerao automtica de stubs para realizar a chamada aos mtodos remotos do Web Service. Desta forma, o desenvolvedor precisa ler o documento WSDL e obter as informaes sobre o mtodo que deseja invocar. A ltima atualizao do projeto foi em 2004, o que mostra que o mesmo no est acompanhando as novas verses de Lua, como a 5.1 utilizada na implementao de referncia do Ginga. Uma das vantagens do projeto que as chamadas aos mtodos remotos no Web Service so sncronas, o que facilita bastante o uso.

5.3.4.2

gSOAP

O gSOAP classicado como um Software Development Kit (SDK) para permitir que aplicaes 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 utilitrio capaz de gerar stubs em C/C++, a partir do documento WSDL do servio. Em tal stub so includos mtodos proxies para realizar chamadas aos mtodos remotos do servio, tornando-as transparentes para a aplicao cliente.

65

As chamadas realizadas com gSOAP tambm so sncronas, o que facilita muito o desenvolvimento das aplicaes clientes, pois o envio da requisio e tratamento da resposta pode ser todo feito em uma nica rotina. Pelo fato do projeto ser desenvolvido em C, o mesmo s poderia ser utilizado em aplicaes de TVD residentes no conversor digital, como j comentado na Seo 5.2. A utilizao de linguagens compiladas como C/C++ permite que o (un)marshalling seja feito em tempo de compilao, o que garante que a aplicao ter maior velocidade na execuo. No entanto, a necessidade de tal processo de compilao elimina a grande vantagem do dinamismo existente em linguagens interpretadas como Lua.

5.3.4.3

Apache Axis

Em [Davis e Parashar 2005] so apresentados alguns outros toolkits para provimento e consumo de Web Services. Um dos projetos citados o Apache Axis, uma implementao de SOAP para Java e C, que tem, como uma das vantagens, o uso do parser XML SAX, o qual completo e bastante eciente. Ele tambm 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 no ser uma soluo ideal para aplicaes 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 no ser ideal em tais equipamentos, alm de poder no estar em conformidade com as normas do Sistema Brasileiro de TV Digital (SBTVD). Parsers mais simples como o NanoXML1 , que demandam menos capacidade de processamento, podem ser mais adequados neste cenrio. Por m, o Apache Axis no atende a um dos requisitos elicitados: ser implementado em Lua para uso direto por aplicaes NCLua.

5.4

Proposta de Novas Implementaes de HTTP e SOAP

O Ginga-NCL prov protocolos de rede at o TCP, assim, qualquer protocolo acima da camada de transporte do modelo OSI precisa ser implementado. Como o envio de envelopes SOAP normalmente feito por HTTP, tal protocolo precisou ser implementado como um mdulo NCLua, ao qual denominou-se NCLua HTTP, que ser utilizado pelo NCLua SOAP.

5.4.1

Decises de Projeto

Para o desenvolvimento do projeto, optou-se por seguir o padro de mdulos, amplamente utilizado na atual verso da linguagem Lua. Um mdulo encapsula funes com objetivos correlatos e tal padro bastante conhecido dos programadores Lua.
1

http://nanoxml.sourceforge.net

66

Tal modelo segue o paradigma de programao estruturada, assim, um mdulo consiste de um conjunto de funes que so chamadas pelo desenvolvedor que for utiliz-lo. Na gerao das requisies SOAP, optou-se por fazer o (un)marshalling de XML para tabelas Lua por estas serem as estruturas de dados padres disponibilizadas pela linguagem e por serem estruturas bastante exveis e fceis de manipular, devendo ser de conhecimento de qualquer programador Lua. Como o contedo das requisies HTTP e SOAP apenas texto, formatado segundo o padro de cada protocolo, a gerao e formatao deste contedo foi bastante simples e direta. Devido a strings em Lua serem imutveis[Ierusalimschy 2006], para economizar memria na concatenao das strings que compe cada requisio, as tabelas de Lua foram utilizadas como um buffer de strings para otimizar o uso de memria RAM. Na obteno dos resultados, procurou-se facilitar ao mximo tal tarefa para o desenvolvedor, permitindo que ele tenha acesso direto aos dados retornados, sem precisar conhecer o caminho dentro do XML de retorno onde a resposta est armazenada, assim como fazem outros toolkits SOAP como a API JAX-WS. Quanto ao parser XML escolhido, no haviam muitas opes implementadas inteiramente em Lua. Todas as implementaes testadas foram encontradas em http:// lua-users.org e em [Ierusalimschy 2006]. Optou-se pelo uso do LuaXML2 , pois foi a implementao que fazia o unmarshalling de XML para tabelas Lua com a estrutura mais simples e fcil de manipular. Alm do mais, as outras implementaes encontradas no funcionaram adequadamente para XMLs mais complexos retornados por alguns Web Services.

5.4.2

NCLua HTTP

O NCLua HTTP3 implementa alguns dos principais recursos do protocolo HTTP/1.0. Ele um mdulo 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 mdulo possui apenas algumas funes que permitem a gerao de requisies e tratamento de respostas. Atualmente existem os seguintes recursos implementados: suporte autenticao bsica, uso de portas especcas e download de arquivos; suporte requisies GET e POST ; passagem de parmetros em requisies POST ; suporte passagem de cabealhos HTTP e denio de User-Agent;
2 3

http://lua-users.org/wiki/LuaXml http://ncluahttp.manoelcampos.com e http://labtvdi.unb.br

67

 suporte separao automtica dos dados do cabealho e do corpo da resposta de uma requisio.

5.4.3

NCLua SOAP

O NCLua SOAP4 implementa as principais funcionalidades do protocolo SOAP 1.1 e 1.2. Ele tambm um mdulo inteiramente escrito em Lua, que faz o parse de arquivos XML, realizando o marshalling e unmarshalling de/para tabelas Lua, permitindo que o desenvolvedor Lua trabalhe com a estrutura de dados principal da linguagem: o tipo table. O mdulo utiliza o NCLua HTTP para transportar as mensagens SOAP. Assim, todos os detalhes do protocolo HTTP so encapsulados pelo respectivo mdulo. Com isto, a implementao do SOAP ca bastante simplicada, tornando o cdigo fcil de ser mantido. O NCLua SOAP encarrega-se apenas de gerar o XML da requisio SOAP, utilizando o NCLua HTTP para enviar tal XML no corpo da mensagem. O parse e unmarshalling do XML para uma tabela Lua todo encapsulado pelo mdulo LuaXML5 . Um importante recurso, no disponvel em implementaes como o LuaSOAP (citada na Seo 5.3), e que facilita bastante a utilizao do mdulo, a simplicao do XML retornando como resposta, que convertido (unmarshalling) automaticamente para uma tabela Lua. Para demonstrar este recurso, utilizar-se- o Web Service de consulta de endereo a partir de um CEP, disponvel em http://www.bronzebusiness.com.br/ webservices/wscep.asmx. Tal WS possui um mtodo chamado "cep", que recebe um determinado CEP e retorna o endereo referente ao mesmo. O XML do retorno do mtodo "cep", convertido para uma tabela Lua, semelhante ao mostrado na Listagem 5.1. A estrutura da tabela reete o cdigo XML retornado. Como pode ser visto, o elemento da tabela que contm de fato os dados do endereo retornado (tbCEP) est envolvido em vrias outras tabelas que no contm dado algum, sendo estruturas completamente desnecessrias para a aplicao NCLua. Com isto, para o desenvolvedor poder acessar, por exemplo, a cidade do CEP indicado, precisar conhecer toda a estrutura retornada, utilizando uma instruo como result.cepResult.diffgr.NewDataSet.tbCEP.cidade. Para esconder estes detalhes do desenvolvedor, o NCLua SOAP simplica qualquer resultado que contenha estruturas desnecessrias, como o mostrado na Listagem 5.1. Listagem 5.1: Exemplo de tabela Lua gerada a partir do XML de uma resposta SOAP
1 2 3

{ c e p R e s u l t = { d i f f g r = { NewDataSet = { tbCEP = { nome="Cln 407" , b a i r r o ="Asa Norte" , UF="DF" , c i d a d e ="Brasilia" } } } } }

Desta forma, para o exemplo citado, a tabela Lua (gerada a partir do XML de retorno da requisio) car como apresentado na Listagem 5.2, o que simplica o acesso aos ele4 5

http://ncluasoap.manoelcampos.com e http://labtvdi.unb.br 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 instruo result.cidade. Listagem 5.2: Exemplo de simplicao de retorno de resposta SOAP pelo NCLua SOAP
1

nome="Cln 407" , b a i r r o ="Asa Norte" , UF="DF" , c i d a d e ="Brasilia"

O mdulo ainda conta com um script (wsdlparser.lua), em fase inicial de implementao, que realiza o parse de um documento WSDL e obtm algumas das informaes que precisase passar ao NCLua SOAP para que ele realize a requisio (como o namespace do servio, o nome do mtodo desejado e a lista de parmetros de entrada). Atualmente o script apenas l o WSDL e exibe algumas das informaes citadas, cabendo ao desenvolvedor copi-las e pass-las ao mtodo call do NCLua SOAP para realizar a chamada a um determinado mtodo remoto. No entanto, a extrao de tais informaes j ajuda de alguma forma, principalmente os usurios menos experientes na tecnologia de Web Services e no NCLua SOAP. Para resumir, as caractersticas principais do NCLua SOAP so: suporte a SOAP 1.1 e 1.2; suporte a parmetros de entrada e sada do tipo struct e array (sendo feito marshalling e unmarshalling de/para tabelas Lua automaticamente); facilidade para manipulao de chamadas assncronas, caracterstica do protocolo TCP disponvel no Ginga-NCL; simplicidade na obteno do retorno de uma requisio a um mtodo remoto; suporte a SOAP Fault para captura de erros SOAP; suporte a SOAP Header[W3C 2007] possibilitando a passagem de parmetros especcos da aplicao (como informaes sobre autenticao, pagamento, etc); realizao de testes com Web Services desenvolvidos em diferentes linguagens. A Figura 5.3 apresenta um diagrama de componentes dos mdulos implementados. O mdulo event faz parte do Ginga-NCL e responsvel por tratar eventos, como requisies e obteno de respostas por meio do protocolo TCP. Ele a base para toda a implementao. O mdulo tcp.lua facilita o gerenciamento das requisies TCP assncronas, geradas por meio do mdulo event. O mdulo ncluahttp.lua implementa o protocolo HTTP, utilizando o TCP como camada de transporte. O mdulo ncluasoap.lua implementa o protocolo SOAP, utilizando o ncluahttp.lua para enviar os envelopes SOAP por HTTP. Uma aplicao cliente, que queira utilizar o protocolo HTTP (NCLua HTTP Client App), pode fazer uso direto das funes do mdulo ncluahttp.lua, abstraindo todos os outros mdulos. Uma aplicao cliente, que queira consumir Web Services SOAP (NCLua Web Service Client App), pode fazer uso direto das funes do mdulo ncluasoap.lua, tambm abstraindo todos os outros mdulos.

69

Figura 5.3: Diagrama de Componentes do NCLua SOAP e NCLua HTTP

5.5

Exemplos de Uso e Testes de Interoperabilidade

Nesta seo so apresentados os exemplos de utilizao e aplicaes desenvolvidas utilizando os mdulos NCLua HTTP e NCLua SOAP, bem como testes de interoperabilidade realizados.

5.5.1

Exemplos de uso do NCLua HTTP

A utilizao bsica do mdulo NCLua HTTP por meio de uma chamada GET a uma determinada URI, utilizando o mtodo request do mdulo, como exemplicado no script NCLua da Listagem 5.3. Tal exemplo envia uma requisio HTTP GET para a pgina em http://manoelcampos.com/votacao/votacao2.php, enviando um parmetro "voto"com valor igual a "sim", obtendo o resultado (um cdigo HTML neste caso) e exibindo no terminal. No existe interface grca neste exemplo, desta forma, o script contm apenas detalhes da requisio HTTP, mas inteiramente funcional. Na Listagem 5.3, a linha 1 adiciona o mdulo NCLua HTTP. A linha 8 chama a funo http.request que envia a requisio HTTP. Devido particularidade assncrona do protocolo TCP no Ginga-NCL (que utilizado para transportar as mensagens HTTP), como explicado na Seo 5.3.3, para facilitar o envio de requisies e recebimento de respostas, o mdulo NCLua HTTP utiliza co-rotinas de Lua. Por este motivo, a obteno do retorno deve ser feita dentro de uma funo, como a denida na linha 6, contendo os parmetros header e body (comentados na denio da mesma). Tal funo deve ser passada como parmetro funo http.request, para que seja chamada por esta quando a resposta for obtida. Listagem 5.3: Exemplo de envio de requisio GET com NCLua HTTP
1 2 3 4 5 6 7 8

r e q u i r e "http" Funcao de c a l l b a c k e x e c u t a d a de f o r m a a s s i n c r o n a p e l o modulo , quando a r e s p o s t a da r e q u i s i c a o eh o b t i d a . @param h e a d e r H e a d e r s HTTP e n v i a d o s na r e s p o s t a @param body Corpo da mensagem HTTP f u n c t i o n g e t R e s p o n s e ( h e a d e r , body ) p r i n t ( "Resposta obtida\n" , body ) end h t t p . r e q u e s t ( "http://manoelcampos.com/voto.php?voto=sim" , g e t R e s p o n s e )

O envio de requisies POST bastante semelhante ao exemplo apresentado anteriormente. Neste caso, os parmetros devem ser passados funo http.request por meio de

70

uma tabela Lua. A formatao destes valores, como exigido pelo protocolo HTTP, feita automaticamente pelo NCLua HTTP. Algumas aplicaes foram desenvolvidas como prova de conceito do uso do mdulo NCLua HTTP, as quais so apresentadas a seguir: Enquete TVD: enquete com registro de voto e apurao a partir de servidor Web; NCLua RSS Reader: leitor de notcias RSS de um provedor de contedo na Web; NCLua Tweet: envio e recebimento de mensagens pelo micro blog Twitter.

5.5.2

Exemplos de uso do NCLua SOAP

A seguir so apresentados exemplos de uso do NCLua SOAP para consumo de alguns Web Services disponveis na Internet. A Listagem 5.4 apresenta um exemplo de aplicao para exibir a previso do tempo de uma cidade. A mesma no possui interface grca, mostrando o resultado no terminal, para simplicar o cdigo. A linha 10 realiza a chamada ao mtodo remoto. Os dados para realizao da requisio (incluindo o endereo do servio, nome do mtodo remoto e parmetros de entrada) devem ser informados em uma tabela Lua, como mostrado entre as linhas 4 a 8. A obteno do retorno do mtodo remoto no direta, devido caracterstica assncrona do protocolo TCP no Ginga-NCL, como j explanado nas Sees 5.3.3 e 5.4.2. Desta forma, necessria a denio de uma funo que deve receber apenas um parmetro (normalmente nomeado de result), como a funo getResponse exibida na linha 2. Tal funo deve ser passada como parmetro ao mtodo call do mdulo ncluasoap, como mostrado na linha 10. O envio da requisio ser executado dentro de uma co-rotina Lua, criada pelo NCLua SOAP. A funo getResponse ser executada automaticamente quando o retorno for obtido. Desta forma, todo o controle das chamadas assncronas feito pelo NCLua SOAP, como j amplamente discutido na Seo 5.4.2. Como o servio consumido neste exemplo retorna apenas uma string com a previso do tempo (chuvoso, nublado, ensolarado, etc), para exibir tal resultado basta imprimir o parmetro result da funo getResponse, como apresentado na linha 6. Listagem 5.4: Exemplo de consumo de Web Service de previso do tempo
1 2 3 4 5 6 7 8

r e q u i r e "ncluasoap" f u n c t i o n g e t R e s p o n s e ( r e s u l t ) p r i n t ( "Previsao do Tempo: " , r e s u l t ) end l o c a l msg = { a d d r e s s = "http://www.deeptraining.com/webservices/weather.asmx" , n a m e s p a c e = "http://litwinconsulting.com/webservices/" , o p e r a t i o n N a m e = "GetWeather" , p a r a m s = { C i t y = "New York" } }

71

9 10

n c l u a s o a p . c a l l ( msg , g e t R e s p o n s e )

O exemplo apresentado na Listagem 5.5 consume um servio para obteno de um endereo a partir do CEP. Observe que o que muda entre as linhas 6 e 10, em relao ao exemplo anterior, so apenas os valores da tabela "msg", que contm os dados para gerao da requisio SOAP. Na funo getResponse, entre as linhas 2 e 4, note que agora, o resultado retornado um tipo composto, que acessado como uma tabela Lua. Tal tabela conter campos com os valores armazenados no XML enviado pelo Web Service. Listagem 5.5: Exemplo de consumo de WS de consulta de endereo a partir do CEP
1 2 3 4 5 6 7 8 9 10 11 12

r e q u i r e "ncluasoap" function getResponse ( r e s u l t ) 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 . c i d a d e , r e s u l t . UF ) end l o c a l msg = { a d d r e s s = "http://www.bronzebusiness.com.br/webservices/wscep.asmx" , n a m e s p a c e = "http://tempuri.org/" , o p e r a t i o n N a m e = "cep" , p a r a m s = { s t r c e p = "70855530" } } n c l u a s o a p . c a l l ( msg , g e t R e s p o n s e )

Algumas aplicaes foram desenvolvidas como prova de conceito de utilizao do mdulo. Entre elas esto o rastreamento de encomendas postadas pelos Correios, consulta de cotao do Dlar, previso do tempo, consulta de endereo a partir do CEP e outras. 5.5.2.1 Testes de Interoperabilidade

Os diversos servios consumidos pelas aplicaes apresentadas so desenvolvidos em diferentes linguagens e plataformas. Procurou-se realizar testes com estes diferentes servios para vericar a interoperabilidade do NCLua SOAP (um dos requisitos fundamentais, se no o mais importante, para qualquer implementao SOAP). Com os testes realizados pde-se comprovar a ecincia do mdulo, uma vez que para todos os servios testados, obteve-se o retorno esperado, tratando-o de forma padronizada. No incio, alguns usurios do frum do projeto relataram problemas ao utilizar servios desenvolvidos em linguagem Java. Os problemas encontrados foram devido aos Web Services criados com a API JAX-WS, padro da plataforma Java, especicarem os tipos de dados utilizados pelo servio em um arquivo XSD (XML Schema Denition) externo, no lugar de especicar diretamente dentro do documento WSDL. Tal caracterstica requer pequenas mudanas no formato da mensagem SOAP a ser enviada para consumir tais Web Services. Assim, foi preciso adequar o mdulo para entrar em conformidade com o padro SOAP. Particularidades encontradas em Web Services PHP tambm foram relatadas e o mdulo

72

foi adequado para permitir a interoperabilidade com tais servios. importante ressaltar que, no caso de tais servios PHP, estes foram desenvolvidos utilizando o tookit nuSOAP6 . Tal tookit no leva em conta os nomes dos parmetros de entrada e sim a ordem dos mesmos, no estando em conformidade com o padro SOAP. Assim, o problema especco da implementao do nuSOAP, mas que foi contornado pelo NCLua SOAP para evitar quaisquer 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 realizao das tarefas de desenvolvimento: ferramentas telnet e curl para teste de envio de requisies HTTP/SOAP geradas com os mdulos 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 LuaDoc7 para gerao de documentao; implementao de referncia do Ginga-NCL (Ginga Virtual Set-top Box 0.11.2): mdulo tcp.lua8 para envio de requisies TCP; mdulo LuaXML para tratamento de XML; mdulo LuaProler9 para realizao das anlises de desempenho, descritas na Seo 5.7. interpretador Lua para execuo do script wsdlparser.lua fora do Ginga Virtual Set-top Box.
6 7

http://sourceforge.net/projects/nusoap http://luadoc.luaforge.net 8 http://www.lua.inf.puc-rio.br/~francisco/nclua/ 9 http://luaprofiler.luaforge.net

73

5.7
5.7.1

Avaliao de Desempenho e Comparaes

Avaliao de Desempenho do NCLua SOAP

Utilizando-se a ferramenta LuaProler (que precisou ter seu processo de compilao alterado para funcionar em aplicaes NCLua10 ) foram feitas algumas anlises do desempenho do NCLua SOAP para avaliar o tempo gasto para gerao da requisio SOAP. Por meio da funo collectgarbage da biblioteca padro de Lua, pde-se vericar o total de memria consumida pelo mdulo. 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 obteno deste percentual, executou-se a aplicao NCL (que no inicia o script Lua automaticamente) e vericou-se o uso da CPU pelo processo de nome "ginga"(responsvel pela execuo das aplicaes interativas) no momento em que este se tornava estvel. Em seguida, por meio de um comando na aplicao NCL, o script Lua ento executado, gerando e enviando a requisio SOAP. Aps isto, vericou-se o pico de uso do processador, considerando que os scripts Lua testados somente enviam a requisio SOAP e exibem o retorno no terminal. Com a diferena entre o pico de uso do processador depois da execuo do script e o valor observado antes do incio do mesmo, obtm-se o percentual de uso do processador pelo NCLua SOAP. A Tabela 5.1 apresenta os resultados obtidos para algumas das aplicaes testadas.
Web Service consumido Parmetros de entrada Tempo de gerao da requisio: chamada ao mtodo call (em segundos) 0.13 Uso de Memria RAM (em KB) 121.78 % de Uso da CPU

Situao do tempo http://www.deeptraining. com/webservices/weather. asmx Converso de Moeda http://www.webservicex. net/CurrencyConvertor.asmx Consulta de endereo a partir do CEP http://www.maniezo.com.br/ webservice/soap-server.php

City = "Braslia"

0.3

FromCurrency = "USD" ToCurrency = "BRL" cep = "77021682"

0.13

121.65

0.3

0.13

133.17

0.3

Tabela 5.1: Avaliao de Desempenho do NCLua SOAP Como pode ser observado na Tabela 5.1, o tempo para gerao da requisio, ou seja, a chamada ao mtodo call do mdulo, na implementao de referncia do Ginga (Ginga Virtual Set-top Box, verso 0.11.2) est em torno de 0.13 segundo. O mtodo call inclui a converso dos dados passados em uma tabela Lua para o formato XML para serem enviados ao Web Service. Tal mtodo no aguarda a conexo ao servidor Web e nem o envio e resposta da requisio, pois tais operaes so assncronas no Ginga-NCL. Assim, o tempo de execuo do mtodo call reete apenas o tempo de gerao da requisio SOAP. Os tempos
10

http://goo.gl/42CQA

74

obtidos nos testes no variaram muito, e a variao vai depender apenas do total de parmetros passados. O uso de memria RAM tambm cou baixo, em torno de 120KB, que varia de acordo com os parmetros de entrada e sada do mtodo remoto. Em todos os exemplos executados, pde-se observar que o percentual de uso da CPU se manteve estvel em 0.3%, sendo um valor consideravelmente baixo. Foram feitas anlises do uso direto do mdulo tcp.lua para vericar o overhead causado pelo NCLua SOAP, que uma camada sobre o tcp.lua. Nos trs exemplos apresentados na Tabela 5.1, o tempo de uso da CPU se manteve tambm estvel e igual aos valores obtidos com o NCLua SOAP, 0.3%. No foram feitas medidas quanto ao tempo gasto (em segundos) para gerao da requisio, pois, para uso direto do tcp.lua, o desenvolvedor precisa passar ao mdulo uma string j com a requisio SOAP formatada. Assim, no h um delay para gerao da requisio pois o tcp.lua recebe a mesma pronta para envio (o que bastante complicado para o desenvolvedor gerar manualmente tal requisio HTTP/SOAP, alm de ser totalmente inexvel). Quanto ao consumo de memria RAM, o uso direto do tcp.lua permite uma otimizao neste sentido, uma vez que a quantidade de varveis e estruturas de dados declaradas muito menor, considerando que o mdulo deve receber a requisio pr-formatada. Para o primeiro exemplo da Tabela 5.1, a aplicao consumiu 76.02 KB de memria RAM, para o segundo consumiu 75.59 KB e para o terceiro exemplo consumiu 66.28 KB. Tais valores mostram que o consumo de memria est em torno de 50% do consumido pelo NCLua SOAP. Foram feitas aplicaes para consumir os mesmos Web Services apresentados na Tabela 5.1 utilizando o mdulo LuaSOAP. No entanto, a aplicao funcionou apenas para o Web Service de obteno de endereo a partir do CEP, que implementa o SOAP 1.1. Para os outros Web Services testados, que implementam SOAP 1.2, o LuaSOAP no enviou a requisio no formato esperado e os Web Services retornaram mensagens de erro. O LuaSOAP um projeto que no tem atualizaes desde 2004, assim, tais problemas eram esperados. Com o Web Service de busca de endereo, a aplicao consumiu 139.20KB de memria RAM, cerca de 6KB a mais que com o NCLua SOAP. O tempo de gerao da requisio 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 devido ao mesmo utilizar mdulos escritos em C, que por serem compilados, tm este ganho de desempenho. Quanto ao uso de CPU, a aplicao 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 devido ao fato de uso do parser XML Expat, que uma implementao mais completa que o LuaXML usado no NCLua SOAP. Com tais valores apresentados anteriormente, considera-se que o NCLua SOAP bastante eciente em questes de tempo de processamento e uso de memria. Presume-se que o tempo de processamento pode ser reduzido em um hardware dedicado como o dos Set-top

75

Boxes, pois os testes foram realizados em uma sistema operacional Linux com vrias aplicaes em execuo e em uma mquina virtual (cujo desempenho inferior a de uma mquina real com nalidades especcas).

5.7.2

Comparativo entre os mdulos implementados e o uso direto do mdulo tcp.lua

Nesta seo feito um comparativo entre aplicaes desenvolvidas utilizando os mdulos implementados e o uso direto do mdulo tcp.lua[SantAnna 2010]. O NCLua SOAP, juntamente como o NCLua HTTP, encapsulam toda a complexidade de envio de requisies SOAP por meio do protocolo HTTP, facilitando a utilizao de tais protocolos em aplicaes de TVDi. A quantidade de cdigo necessria para a realizao de requisies HTTP ou SOAP bastante reduzida com os mdulos implementados, permitindo uma maior agilidade no desenvolvimento de aplicaes, alm de minimizar a possibilidade de erros e reduzir a duplicao de cdigo. A Tabela 5.2 apresenta um comparativo do total de linhas existentes em aplicaes utilizando os mdulos desenvolvidos e outras que no os utilizam, mostrando como o cdigo das aplicaes reduzido com o uso dos mdulos implementados. A utilizao dos mdulos no desenvolvimento de aplicaes, alm de reduzir o cdigo das mesmas, libera o desenvolvedor da necessidade de conhecer detalhes de implementao dos protocolos HTTP e SOAP. Sem a utilizao do mdulo tcp.lua, com o uso direto da classe de eventos tcp do Ginga-NCL, o cdigo das aplicaes aumentaria substancialmente, em torno de 100 linhas de cdigo.
Aplicao/Protocolo Enquete/HTTP Cotao do dlar/SOAP Sem mdulos implementados 14 linhas de cdigo 5 funes utilizadas diretamente 64 linhas de cdigo 5 funes utilizadas diretamente Com mdulos implementados 5 linhas de cdigo = 35% do anterior 1 funo usada diretamente 15 linhas de cdigo = 23% do anterior (9 so parmetros do WS) 1 funo usada diretamente

Tabela 5.2: Comparativo entre aplicaes de TVD sem e com os mdulos implementados

5.7.3

Comparativo entre o NCLua SOAP e outras implementaes

A Tabela 5.3 apresenta um comparativo entre alguns toolkits SOAP e o NCLua SOAP.
Caractersticas Linguagem SOAP 1.1 SOAP 1.2 SOAP com Anexos Gerao de cdigo cliente a partir do WSDL Suporte para formato document/literal Requisitos de runtime Documentao Axis Java Sim Sim Sim Sim Bom JVM Boa Axis2 Java Sim Sim Sim Sim Bom JVM Pequena PHP PHP 5 Sim Sim Sim Sim Mdio PHP engine Mdia gSOAP C++ Sim Sim Sim Sim Bom Nenhum Boa NCLua SOAP NCLua Sim Sim Ainda no Ainda no Bom Ginga-NCL Mdia

76

Tabela 5.3: Comparao entre NCLua SOAP e outros toolkits SOAP (adaptada de [Louridas 2006]). Como pode ser observado na Tabela 5.3, o NCLua SOAP s no possui dois dos recursos encontrados nos outros toolkits: suporte a anexos e gerao de cdigo cliente a partir do WSDL. O uso de anexos no algo comumente encontrado nos Web Services disponveis na Web e com os quais foram feitos testes de interoperabilidade. A falta de gerao automtica de cdigo cliente a partir do WSDL no inviabiliza o uso do mdulo, pois tal cdigo pode ser escrito pelo desenvolvedor que desejar consumir algum servio, obtendo manualmente as informaes necessrias no WSDL. No entanto, considera-se que tal recurso facilitar bastante o uso do mdulo.

5.8

Limitaes do mdulo NCLua SOAP

A atual verso do NCLua SOAP possui algumas limitaes, que entendemos no intereferirem no uso do mesmo: necessidade de o desenvolvedor saber a verso do protocolo SOAP do servio que ele deseja consumir; necessidade de extrair manualmente alguns dados como o namespace do servio; falta de tratamento de erros retornados pelo protocolo HTTP, o que causar comportamentos inesperados na aplicao; necessidade de saber se o servio utiliza um arquivo XML Schema Denition (XSD) externo, para poder indicar isto no momento da chamada ao mtodo remoto; no permitir o envio de anexos em formato Multipurpose Internet Mail Extensions (MIME)[IETF 1996] dentro de uma mensagem SOAP.

77

Captulo 6 Concluses e Trabalhos Futuros

6.1 Concluses

As implementaes apresentadas nesta dissertao so todas originais, por no haver nenhuma outra implementao (pelo menos de cdigo aberto) para o sub-sistema Ginga-NCL dos protocolos HTTP e SOAP, de um framework de componentes grcos e de aplicaes de T-Commerce. Tais implementaes permitem o desenvolvimento de aplicaes dos mais variados tipos para o Ginga-NCL, alavancando o desenvolvimento de aplicaes interativas para o SBTVD (ISDB-TB). Os mdulos NCLua HTTP e NCLua SOAP facilitam a convergncia entre Web e TV, escondendo os detalhes de implementao dos protocolos HTTP e SOAP do desenvolvedor de aplicaes de TVDi, permitindo o surgimento de novas aplicaes interativas que fazem uso de contedo da Internet. O NCLua SOAP permitiu o desenvolvimento de aplicaes de T-Government como apresentado em [Barbosa, Kutiishi e Lima 2010], entre outras. Na pgina do projeto, em http://ncluasoap.manoelcampos.com e em http://labtvdi.unb.br, existe um link para o frum de discusso do mdulo, onde alguns usurios relatam a utilizao do mesmo, por exemplo, em aplicaes de recomendao de contedo e T-Learning. Atualmente, o processo de obteno dos dados para realizar a chamada a um mtodo remoto em um Web Service ainda praticamente todo manual, no entanto, aps o desenvolvedor obter tais dados para o mtodo remoto desejado, a realizao da requisio bastante simplicada, principalmente pelo fato de Lua ser uma linguagem de tipagem dinmica, no obrigando a declarao de variveis com seus respectivos tipos. O feedback dos usurios tem mostrado que o mdulo est sendo bastante til para a comunidade, alm de permitir a evoluo do mesmo. A arquitetura proposta serve de base para o desenvolvimento de servios de T-Commerce para o SBTVD, mostrando como diversos servios podem ser integrados em uma nica arquitetura para um propsito nal. Tal arquitetura tambm serve como um estudo de caso

78

dos percalos enfrentados para a elaborao de um ambiente de desenvolvimento e testes de aplicaes para o SBTVD, mostrando as ferramentas necessrias para isto. As anlises de desempenho apresentadas dos protocolos implementados mostraram como a soluo proposta eciente em uso de processador e memria RAM, sendo uma soluo ideal para uso em ambientes restritos de recursos, como os Set-top Boxes. Os protocolos implementados so a base da integrao entre Web e TV e esto sendo bastante teis em diversos outros trabalhos, como apresentado no Captulo 5, mostrando como os resultados alcanados se tornaram importantes para a comunidade de TV Digital no Brasil e na Amrica Latina, onde quase todos os pases j adotaram o ISDB-TB. A aplicao de T-Commerce desenvolvida delineia o processo de desenvolvimento de aplicaes que fogem do trivial, mostrando como aplicar recursos como orientao a objetos na linguagem Lua, uso do canal de retorno/interatividade no SBTVD, uso de arquivos XML e arquivos de dados em formato Lua, alm de outros recursos. O uso do framework LuaOnTV para construo de interfaces grcas de usurio bastante exvel e d suporte a mltiplos dispositivos, adaptao automtica das dimenses dos componentes grcos da aplicao, alm do uso de templates para permitir uma denio centralizada da identidade visual da aplicao. Tal recurso de templates permite alterar a identidade visual da aplicao facilmente, podendo-se ter templates diferentes para tipos de dispositivos diferentes (como TVs e celulares). Outras aplicaes foram desenvolvidas, como o NCLua RSS Reader e o Rastreador de Encomendas que servem como prova de conceito dos protocolos como HTTP e SOAP, implementados nesta dissertao. Os objetivos apresentados na Seo 1.1 foram todos alcanados, apresentando uma soluo completa, desde o ambiente de desenvolvimento, at a realizao de anlises de desempenho das aplicaes desenvolvidas. A Tabela 6.1 apresenta uma descrio de como tais objetivos foram alcanados.

79

Objetivo Especco A B

Como foi alcanado Os requisitos funcionais e no funcionais foram elicitados, tendo servido de guia para o desenvolvimento da arquitetura proposta; a arquitetura foi proposta e desenvolvida, apresentando-se a mesma por meio de guras e diagramas UML, alm da montagem de uma distribuio GNU/Linux contendo todo o ambiente de desenvolvimento elaborado; um framework de comunicao de dados foi desenvolvido, composto pelos mdulos NCLua HTTP e NCLua SOAP, que implementam os protocolos HTTP e SOAP, respectivamente, sendo a base de toda a interoperao das aplicaes desenvolvidas com diferentes provedores de servios Web; as diferentes aplicaes de TVDi propostas foram desenvolvidas e apresentadas, servindo como prova de conceito do uso dos frameworks desenvolvidos ou estendidos; o framework LuaOnTV foi estendido, incluindo-se suporte a temas. O recurso de temas foi utilizado na aplicao de T-Commerce desenvolvida. A adaptao automtica da interface da aplicao foi testada em ambiente virtual de TV Digital (o Ginga Virtual Set-top Box) com diferentes resolues de tela. Em tal ambiente, a adaptao automtica do tamanho da interface grca da aplicao ao tamanho da tela do televisor mostrou-se satisfatria, possibilitando que a aplicao de adapte automaticamente a diferentes dispositivos receptores de TVD; um modelo de desenvolvimento de aplicaes de TVDi baseado em templates foi elaborado e apresentado. Tal modelo foi utilizado na aplicao de TCommerce desenvolvida, o que permitiu uma agilidade no desenvolvimento da mesma, denindo um conjunto de componentes grcos bsicos e uma identidade visual comum a todas as telas da aplicao desenvolvida. Tabela 6.1: Objetivos Especcos Alcanados

6.2

Trabalhos Futuros

Como trabalhos futuros, pretende-se concluir a implementao do parser automtico do documento WSDL e gerao de stubs Lua, contendo funes proxies para realizar a chamada aos mtodos remotos (semelhante a ferramentas como o wsdl2java1 , pretende-se transformar o script wsdlparser em um wsdl2nclua) e incluir tratamento de excees para permitir que as aplicaes de TVDi possam emitir mensagens amigveis ao usurio quando uma requisio HTTP falhar. O mdulo NCLua HTTP permite que seja utilizado qualquer mtodo HTTP em uma re1

http://ws.apache.org/axis/java/user-guide.html

80

quisio, no entanto, apenas os mtodo GET e POST foram testados. Desta forma, pretendese realizar testes de conformidade utilizando-se os mtodos HTTP OPTIONS, HEAD, PUT e DELETE. Pretende-se tambm implementar mais funcionalidades no mdulo, como realizar redirecionamentos automaticamente a partir de respostas HTTP como 301 e 302, alm de implementar alguns recursos do HTTP/1.1, como conexes persistentes. A arquitetura tambm pode ser estendida nos pontos a seguir: incluir suporte a metadados na aplicao 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 sincronizao de mdias existente na linguagem NCL; estudar a viabilidade e uso do protocolo de autorizao Open Authentication (oAuth)2 , que bastante utilizado atualmente em redes sociais, permitindo ao usurio ter um login e senha nicos para acesso a diferentes servios, agilizando o processo de login (caso o usurio decida salvar localmente, de forma criptografada, as informaes de autorizao); estender a arquitetura para um modelo baseado em descoberta de servios que possibilite a integrao de diferentes lojas virtuais que implementem a arquitetura aqui proposta, utilizando recursos como a linguagem BPEL (Business Process Execution Language) para permitir a composio de servios e tornar tal integrao transparente para aplicao de TVDi; utilizar a extenso WS-Security[OASIS 2006] para permitir a segurana na comunicao entre os Web Services e as aplicaes cliente; criar ferramenta, para execuo do lado da emissora de TV, que permita o envio dos produtos em oferta via broadcast, possibilitando a usurios, sem conexo com a Internet, visualizarem tais produtos na tela de seu equipamento de TVD.

http://oauth.net

81

Referncias Bibliogrcas
[ABNT 2008]ABNT, N. 15606-2. Televiso digital terrestreCodicao de dados e especicaes de transmisso para radiodifuso digital Parte 2: Ginga-NCL para receptores xos e mveisLinguagem de aplicao XML para codicao de aplicaes, 2008. [Barbosa, Kutiishi e Lima 2010]BARBOSA, R. de C.; KUTIISHI, S. M.; LIMA, V. de. Desenvolvendo servios de governo eletrnico multiplataforma para TV interativa utilizando Web Services. Simpsio 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, Padres, Autoria Declarativa e Usabilidade. Atualizaes em Informtica, 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. Introduo segurana de aplicaes para a TV digital interativa brasileira. Simpsio Brasileiro de Segurana (SBSeg 2010), 2010. [CETIC.br 2009]CETIC.BR. Tic Domiclios e Usurios - Pesquisa sobre o Uso das Tecnologias da Informao e da Comunicao 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 framework 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. Segurana para o Sistema Brasileiro de Televiso Digital: Contribuies Proteo de Direitos Autorais e Autenticao de Aplicativos. Dissertao de Mestrado. Escola Politcnica da Universidade de So 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 implementations. 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. [Fernndez e Goldenberg 2008]FERNNDEZ, F.; GOLDENBERG, S. Aplicaciones interactivas para la televisin digital en Chile. Cuadernos de informacin, I, n. 22, p. 12, 2008. [Fielding 2000]FIELDING, R. T. Architectural styles and the design of network-based software 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 estria em So Paulo com transmisso de emissoras abertas. Disponvel 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. Integrao de Aplicaes para TV Digital Interativa com Redes Sociais. Simpsio 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 padro 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.; GUISASOLA, 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: rfc2045. Acessado em: 22 jan. 2011., 1996. http://tools.ietf.org/html/

[InfoExame 2009]INFOEXAME. Ginga-NCL aprovado como padro 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 TELEVISION, SOUND PROGRAMME AND OTHER MULTIMEDIA SIGNALS. Application 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 TELEVISION, 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 TELEVISION, SOUND PROGRAMME AND OTHER MULTIMEDIA SIGNALS. Application 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

[Jnior e Gondim 2009]JNIOR, P. J. S.; GONDIM, P. R. L. LUACOMP: ferramenta de autoria de aplicaes para tv digital. Dissertao de Mestrado. Universidade de Braslia, Brasil., 2009. [KOPECK e Simperl 2008]KOPECK, J.; SIMPERL, E. Semantic web service offer discovery 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. Implementao de um Set-top Box Virtual para Desenvolvimento e Testes de Aplicaes 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. Acessado 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. Documentao NCLua. Disponvel http://www.lua.inf.puc-rio.br/ francisco/nclua/. Acessado em: 10 fev. 2010., 2010. em:

[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 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. Programando em NCL 3.0: Desenvolvimento de aplicaes para o middleware Ginga. [S.l.]: Campus, Rio de Janeiro, 1a. edio., 2009.

J.

[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 Interativa. UNIrevista, v. 1, n. 3, 2006. ISSN 1809-4651. [TeleTime 2010]TELETIME. Totvs lana plataforma de aplicativos para TV digital. 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. Transaction 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. Disponvel 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 Television. Monograa de Bacharelado. EVTEK University of Applied Sciences - Institute of Technology. Finlndia, 2006.

86

Apndice A
Screenshots da aplicao de T-Commerce

Figura 6.1: Aplicao de T-Commerce: Tela inicial com produtos em destaque

87

Figura 6.2: Aplicao de T-Commerce: Busca de produtos

Figura 6.3: Aplicao de T-Commerce: Login (utilizando e-mail ou CPF)

Figura 6.4: Aplicao de T-Commerce: Recuperar senha por e-mail ou SMS

88

Figura 6.5: Aplicao de T-Commerce: Cadastro de Clientes (com busca de endereo a partir do CEP)

Figura 6.6: Aplicao de T-Commerce: Cadastro de Endereos (com busca de endereo a partir do CEP)

89

Figura 6.7: Aplicao de T-Commerce: Seleo de Endereos

Figura 6.8: Aplicao de T-Commerce: Formas de Pagamento

90

Figura 6.9: Aplicao de T-Commerce: Finalizar Compra

91